4.dynamic analysis

DYNAMIC ANALYSIS
Chapter 401/12/18
4. Dynamic Testing/D.S.Jagli 1

Topics to be covered.
I. Black Box Testing:
1. Equivalence Class Partioning,
2. Boundary Value Analysis,
3. State Transition Test,
4. Cause Effect Graphing and Decision Table Technique
5. User Documentation Testing
6. Advanced black box Techniques
II. White Box Testing Strategies
1. Statement Coverage,
2. Branch Coverage,
3. Test of Conditions,
4. Path Coverage,
01/12/184. Dynamic Testing/D.S.Jagli
2

The Procedure to Dynamic Testing
a) Testing of S/W by executing test objects.
b) Systematic approach at determination of the test
cases(different techniques).
c) Defining test exit criteria.
d) Examples for each technique.
3

Execution Of The Test Object On A
Computer
 The test object (program) must be executable
 It is provided with input data
 In the lower test stages the test object cannot be run alone,
must be embedded into a test bed.
 What is a test bed?
 Driver and stub combined establish the test bed.
 What is a stub and test Driver?
 The test object will call different parts of the program
through predefined interfaces. these parts of the program
are substituted by placeholders called stubs
 A software component or test tool that replaces a program
that takes care of the control and/or the calling of a
component or system is called Test Driver01/12/184. Dynamic Testing/D.S.Jagli
4

Execution Of The Test Object On A
Computer
 Why test bed is necessary?
 … because
1. The test object will call different parts of the program
through predefined interfaces.
2. All parts are not yet implemented, not ready to be used.
3. It is necessary to simulate a part of the program.
4. The test bed must supply the test object with input data.
5. The tester must expand or modify standard (generic) test
beds, adjusting them to the interfaces of the test object.
• Test bed generators can be used
5

Test bed
6
It is provided with input data before it is executed

Systematic approach at
determination of the test cases
 when executing a program(goal)
 testing must expose failures
 verify as many requirements
 as possible with as little expense
 Unstructured testing, usually "by gut feeling", does
not offer any guarantee.
7

Incremental Approach For
Executing Test Cases
 The following steps are necessary to execute the
test case:
1) Determine conditions and preconditions for the test and
the goals that are to be achieved
 Eg:test should show that time constraints are met
 being the necessary data in a database.
1) Specify the individual test cases
 E.g.: test input data, The expected results
1) Determine how to execute the tests (usually chaining
together several test cases)
 Test cases should be grouped
 test procedure specifications
 test schedule.
 test script is required 01/12/184. Dynamic Testing/D.S.Jagli
8

Defining Test Exit Criteria
 The set of generic and specific conditions, agreed upon with
the stakeholders, for permitting a process to be officially
completed.
 The purpose of exit criteria is to prevent a task from being
considered completed when there are still outstanding parts of
the task which have not been finished.
 Note: Exit criteria are used by testing to report against and to plan when
to stop testing.
9

Black Box and White Box
Techniques
10

Black Box And White Box
Techniques
1. The black box testing techniques
are known as functional or
behavioral testing.
2. Test cases are derived from the
specification.
3. The behavior of the test object is
watched from the outside.
4. PoO Point of observation(PoO) is
outside the test object
5. It is possible to control the
operating sequence of the test
object by choosing the adequate
input test data (PoC is out side)
6. Black box testing is used for
higher levels of testing
1. White box testing is also called
structural testing
2. the source code is known and used
for test design
3. internal processing of the test
object, output are analyzed
4. the Point of Observation is inside
of the test object
5. Direct intervention in the process
of the test object is possible (PoC
is inside)
6. White box testing can be applied at
the lower levels of the testing
Black box testing White Box Testing
01/12/18
11
4. Dynamic Testing/D.S.Jagli

What is a black box testing?
 Using black box testing, the inner structure and design of the
test object is unknown, or not considered to test correct
behavior of system.
 The test cases are derived from the specification, are already
available as part of the specification.
Why black box testing?... because.
 Helps in overall functionality verification
 Helps in identifying inconsistent and incomplete
requirements.
 It includes end user prospective.
 Designing test cases is easy.
12

FUNCTIONAL(BEHAVIOURAL) TESTING
4.1. Black Box Testing
Techniques
01/12/18
13

Types Of Techniques For Black
Box Testing
1. Equivalence partioning
2. Boundary value analysis
3. Cause effect graph
4. State transition testing
5. User Documentation Testing
6. Advanced black box Techniques
14

VALID AND INVALID
4.1.1. Equivalence Class Partitioning
01/12/18
15

Equivalence Class Partitioning
 1. Equivalence Class Partitioning
 Input domains are divided into equivalence classes
 Equivalence classes with correct values
 Equivalence classes with incorrect values
 Correct equivalence classes and representatives
 E.g.: the calculation of the Christmas bonus
16

Example:
 Company orders an application that is supposed to calculate
the Christmas bonus of the employees depending on the
length of their company affiliation. In the description of the
requirements the following is found: "Employees with a
company affiliation of more than three years, get 50% of their
monthly salary as Christmas bonus. Employees that have
been working more than five years in the company get 75%.
With an affiliation greater than eight years, a 100% bonus
will be given".
17

Black Box Testing Techniques
Contd…
 E.g:the calculation of the Christmas bonus
18
Parameter Equivalence classes Representative
values
Bonus calculation
program, duration of
employment in years
vEC1: 0 <= x <= 3
vEC2: 3 < x <= 5
vEC3: 5 < x <= 8
vEC4: x > 8
2
4
7
12

Equivalence classes with incorrect
values
19
Parameter Equivalence classes Representative
values
Bonus calculation
program, duration of
employment in years
iEC1: x < 0
("Negative" – thus incorrect –
staff membership in a
company)
-3
iEC2: x > 70
(Unrealistically long and
incorrect staff membership in
a company[]
)
80

Systematic Derivation Of Test
Cases
1. Further partitioning of the equivalence classes
 The equivalence classes should be divided until each different
requirement corresponds to an equivalence class.
1. Equivalence classes for output values
 The same principle of dividing into equivalence classes for the
output data
1. Boundaries of the equivalence classes
 The best test values are verifying the boundaries of the equivalence
classes.
1. Equivalence classes of input values, which are not basic
data types
 Besides the basic data types, data structures and sets of objects can
occur 01/12/184. Dynamic Testing/D.S.Jagli
20

Boundaries Of The Equivalence
Classes
21
Equivalence classes and representatives for
integer values
Parameter Equivalence classes Representatives
Employee
Affiliation
vEC1: [MIN_INT, ..., 0[[]
vEC2: [0, ..., MAX_INT]
iEC1: NaN (Not a Number)
61
100
"f"

Equivalence Classes-not Basic
Data Types
 Example for input values to be selected from a set
 A traveler can be a child, a teenager, an adult, a student, a
person on welfare, or a retired person.
 If the test object needs to react differently to each kind of
traveler, then every possibility must be verified with an
additional test case.
 If there is no requirement for different reactions for each
person type, then one test case might be sufficient..
 For the test of the component that handles the seat
reservation, one test case.
22

Hint for determining equivalence
classes
1. For the inputs as well as for the outputs, identify the
restrictions and conditions in the specification.
2. If a continuous numerical domain is specified, then create one
valid and two invalid equivalence classes.
3. If a set of values is specified where each value may be treated
differently, one valid and one invalid equivalence class.
4. If there is a condition that must be fulfilled, then create one
valid and one invalid
5. If the values of one equivalence class are treated equally, the
equivalence class should be further divided into subclasses.
23

Test Cases
 Rules for test case determination
I. Restriction of the number of test cases
II. Separate test of the invalid value
I. Rules for test case restriction
I. Combine the test cases and sort them by frequency of
occurrence
II. Test cases including boundary values are preferred.
III. Combine every representative of one equivalence class
with every representative of other equivalence classes.
IV. Representatives of invalid equivalence classes should
not be combined with other invalid equivalence classes.
01/12/18
24

Example
25

The Programming code
26

Steps For Equivalence Classes
1. Identifying the domain
2. Refine the equivalence classes based on the
specification
3. Select representatives
4. Combine the test cases
27

1: Identifying The Domain
Equivalence classes for integer input values
Parameter Equivalence classes
baseprice vEC11: [MIN_DOUBLE, ..., MAX_DOUBLE]
iEC11: NaN
specialprice vEC21: [MIN_DOUBLE, ..., MAX_DOUBLE]
iEC21: NaN
extraprice vEC31: [MIN_DOUBLE, ..., MAX_DOUBLE]
iEC31: NaN
extras vEC41: [MIN_INT, ..., MAX_INT]
iEC41: NaN
discount vEC51: [MIN_DOUBLE, ..., MAX_DOUBLE]
iEC51: NaN
28

2: Refine The Equivalence Classes
Based On The Specification
29

01/12/184. Dynamic Testing/D.S.Jagli30
Further partitioning of the equivalence classes of the parameter of the function
Calculate_price() with representatives
Parameter Equivalence classes Representatives
baseprice vEC11: [0, ..., MAX_DOUBLE] 20000.00
iEC11: [MIN_DOUBLE, ..., 0[
iEC12: NaN
-1.00
"abc"
specialprice vEC21: [0, ..., MAX_DOUBLE] 3450.00
iEC22: NaN
-1.00
"abc"
extraprice vEC31: [0, ..., MAX_DOUBLE] 6000.00
iEC32: NaN
-1.00
"abc"
exTRas vEC41: [0, ..., 2]
vEC42: [3, 4]
vEC43: [5, ..., MAX_INT]
1
3
20
iEC41: [MIN_INT, ..., 0[
iEC42: NaN
-1.00
"abc"
discount vEC51: [0, ..., 100] 10.00
iEC : [MIN_DOUBLE, ..., 0[ -1.00

 3:Select representatives
 4: Combine the test cases
 Further partitioning of the equivalence classes of the
parameter Test cases of the function Calculate_price()
31

01/12/184. Dynamic Testing/D.S.Jagli32
Further partitioning of the equivalence classes of the parameter Test cases of
the function Calculate_price()
Test case baseprice
specialpric
e extraprice extras discount result
1 20000.00 3450.00 6000.00 1 10.00 27450.00
2 20000.00 3450.00 6000.00 3 10.00 26850.00
3 20000.00 3450.00 6000.00 20 10.00 26550.00
4 -1.00 3450.00 6000.00 1 10.00 NOT_VALID
5 "abc" 3450.00 6000.00 1 10.00 NOT_VALID
6 20000.00 -1.00 6000.00 1 10.00 NOT_VALID
7 20000.00 "abc" 6000.00 1 10.00 NOT_VALID
8 20000.00 3450.00 -1.00 1 10.00 NOT_VALID
9 20000.00 3450.00 "abc" 1 10.00 NOT_VALID
10 20000.00 3450.00 6000.00 -1.00 10.00 NOT_VALID
11 20000.00 3450.00 6000.00 "abc" 10.00 NOT_VALID
12 20000.00 3450.00 6000.00 1 -1.00 NOT_VALID
13 20000.00 3450.00 6000.00 1 101.00 NOT_VALID
14 20000.00 3450.00 6000.00 1 "abc" NOT_VALID

Definition of the Test Completion
Criteria
 A test completion criterion for the test by equivalence class
partitioning can be defined as the percentage of executed
equivalence classes in comparison to the total number of
specified equivalence classes.
 EC-coverage = (number of tested EC / total number of
EC) * 100%
◦ Let us assume that 18 equivalence classes have been
defined
◦ only 15 have been executed in the chosen test cases. Then
the equivalence class coverage is 83%.
 EC-coverage = (15/18) * 100% = 83.33%
33

Testing boundaries
4.1.2. Boundary Value Analysis
01/12/18
34

Boundary Value Analysis…
1. Boundary value analysis is a software testing technique in
which tests are designed to include representatives of
boundary values.
2. Boundary value analysis delivers a very reasonable addition
to the test cases that have been identified by the equivalence
classes.
3. While equivalence partitioning selects tests from within
equivalence classes, boundary value analysis focuses on
tests at and near the boundaries of equivalence classes.
4. The foundation behind boundary value testing is that errors
tend to occur near the extreme values of an input variable.
35

Errors at the boundaries
• Experience indicates that programmers make mistakes in
processing values at and near the boundaries of equivalence
classes.
• Programs written in not strongly typed languages are more
appropriate candidates for boundary value testing.
1. It is source of defects /failures
2. It checks the borders of EC
3. Boundaries can defined clearly
•
36

Boundary Value Analysis…
• The basic idea in boundary value analysis is to
select input variable values at their:
▫ Minimum
▫ Just above the minimum
▫ A nominal value
▫ Just below the maximum
▫ Maximum
 On every border 3 values are tested
37

Generalizing Boundary Value Analysis
1. By the number of variables
 n variables → 4n + 1 test cases
1. By the kinds of ranges of variables
 Programming language dependent
 Bounded discrete
 Unbounded discrete (no upper or lower bounds clearly defined)
 Logical variables
1. Boundaries are not existing for sets.
2. Boundary value analysis can also be applied for output
equivalence classes.
38

BVA: Procedure
1. Partition the input domain using unidimensional partitioning.
1. This leads to as many partitions as there are input
variables.
2. Alternately, a single partition of an input domain can be
created using multidimensional partitioning.
2. Identify the boundaries for each partition. Boundaries may
also be identified using special relationships amongst the
inputs.
3. Select test data such that each boundary value occurs in at
least one test input.
39

BVA: Example: 1. Create equivalence
classes
40
Assuming that an item code must be in the range 99..999 and
quantity in the range 1..100,
Equivalence classes for code:
E1: Values less than 99.
E2: Values in the range.
E3: Values greater than 999.
Equivalence classes for qty:
E4: Values less than 1.
E5: Values in the range.
E6: Values greater than 100.

BVA: Example: 2. Identify boundaries
41
E1
E2
E3
98 100 998 1000
99 999
x x* * * *
E4
E5
E6
0 2 99 101
1 100
x x* * * *

BVA: Example: 3. Construct test set
42
Test selection based on the boundary value analysis technique
requires that tests must include, for each variable, values at and
around the boundary. Consider the following test set:
T={ t1: (code=98, qty=0),
t2: (code=99, qty=1),
t3: (code=100, qty=2),
t4: (code=998, qty=99),
t5: (code=999, qty=100),
t6: (code=1000, qty=101)
}

Boundary Value Analysis
 Is the test cost justified?
 we have to decide if the test cost is justified and every
boundary with the adjacent values each must be tested with
extra test cases.
43

Example: Boundary value test for
calculate_price()
Boundaries of the parameters of the function calculate_price()
Parameter
Lower boundary value [Equivalence class] Upper
boundary value
baseprice 0-δ, [0, 0+δ, ..., MAX_DOUBLE-δ,
MAX_DOUBLE], MAX_DOUBLE+δ
specialprice Same values as baseprice
extraprice Same values as baseprice
-1, [0, 1, 2], 3
2, [3, 4], 5
4, [5, 6, ..., MAX_INT-1, MAX_INT],
MAX_INT+1
discount 0-δ, [0, 0+δ, ..., 100-δ, 100], 100+δ
44

Example….
 Considering only those boundaries that can be found inside
equivalence classes, we get 4+4+4+9+4 = 25 boundary based
values.
 baseprice: 0.00, 0.01 , MAX_DOUBLE-0.01,
MAX_DOUBLE
 specialprice: 0.00, 0.01, MAX_DOUBLE-0.01,
MAX_DOUBLE
 extraprice: 0.00, 0.01, MAX_DOUBLE-0.01,
MAX_DOUBLE
 extras: 0, 2, 4, 5, 6, MAX_INT-1, MAX_INT
 discount: 0.00, 0.01, 99.99, 100.00
45

Further test cases for the function
calculate_price()
test cases for the function calculate_price()s
Testcase baseprice specialprice extraprice extras discount result
15 0.00 0.00 0.00 0 0.00 0.00
16 0.01 0.01 0.01 2 0.01 0.03
17 MAX_DO
UBLE-0.01
MAX_DOUBL
E-0.01
MAX_DO
UBLE-
0.01
4 99.99 >MAX_D
OUBLE
18 MAX_DO
UBLE-0.01
3450.00 6000.00 1 10.00 >MAX_D
OUBLE
19 20000.00 MAX_DOUBL
E-0.01
6000.00 1 10.00 >MAX_D
OUBLE
20 20000.00 3450.00 MAX_DO
UBLE-
0.01
1 10.00 >MAX_D
OUBLE
... 01/12/184. Dynamic Testing/D.S.Jagli
46
Test case 15 verifies all valid lower boundaries of equivalence classes of the
parameters of calculate_price().

Early thinking of testing pays off
 The customer has given the following information:
 The baseprice is between 10,000 and 150,000.
 The extraprice for the extra items are between 800 and 3,500.
 There should be maximum of 25 possible extras, whose prices
are between 50 and 750.
 The dealer discount is a maximum of 25%.
 After specifying the equivalence classes, the following valid
boundaries result:
 baseprice: 10000.00, 10000.01, 149999.99, 150000.00
 specialprice: 800.00, 800.01, 3499.99, 3500.00
 extraprice: 50.00, 50.01, 18749.99, 18750.00
 extras: 0, 1, 2, 3, 4, 5, 6, 24, 25 01/12/184. Dynamic Testing/D.S.Jagli
47

Early thinking of testing pays off
 For values outside the valid equivalence classes one test case
is needed for each.
 The following values must be used for these:
 baseprice: 9999.99, 150000.01
 specialprice: 799.99, 3500.01
 extraprice: 49.99, 18750.01
 extras: -1, 26
 discount: -0.01, 25.01
 Adding the "boundary values for the machine"
(MAX_DOUBLE, MIN_DOUBLE, etc.) is a good idea.
 This will detect problems with hardware restrictions.01/12/184. Dynamic Testing/D.S.Jagli
48

Hint on test case design by boundary
analysis
1. For an input domain, the boundaries and the adjacent values outside the
domain must be considered.
2. An input file has a restricted number of data records, between 1 and
100. The test values should be 1, 100 and 0, 101.
3. The output of the test object is an integer value between 500 and 1000.
Test outputs that should be achieved: 500, 1000, 499, 1001.
4. For ordered sets the first and last element is of special interest for the
test.
5. If complex data structures are given as input or output, for instance, an
empty list or zero matrixes can be considered a boundary value.
6. For numeric calculations, values that are close together, & that are far
apart, should be taken into consideration as boundary values.
49

Criteria
 An intended coverage of the boundary values (BV)
can also be predefined and calculated after
execution of the tests.
 BV-Coverage = (number of tested BV/total number of BV) * 100%
50

Limitations of Boundary Value Analysis
 Boundary value analysis works well when the program to be
tested is a function of several independent variables that
represent bounded physical quantities.
 Boundary value analysis selected test data with no
consideration of the function of the program, nor of the
semantic meaning of the variables.
 We can distinguish between physical and logical type of
variables as well (e.g. temperature, pressure speed, or PIN
numbers, telephone numbers etc.)
51
51

The value of the technique
• In combination with equivalence class partitioning
1. Boundary value analysis should be done together with
equivalence class partitioning, because faults are discovered
more often at the boundaries of the equivalence classes than
far inside the classes.
2. Both techniques can be combined easily, but still allow
enough freedom in selecting the concrete test data.
3. The technique requires a lot of creativity in order to define the
according test data at the boundaries.
52

4.1.3. State Transition Testing
01/12/18
53

State Transition Testing …
• Consider history
• In many cases, not only the current input, but also the
history of execution or events or inputs, influences the
outputs
• Definition finite state machine
 "An abstract machine for which the number of states and input
symbols are both finite and fixed.
 e.g., program, logic circuit, car's transmission
 A finite state machine consists of
• states (nodes),
• transitions (links),
• inputs (link weights),
• outputs (link weights).
54

Example: Stack
 The popular example of a stack is supposed to
clarify the circumstances.
 The stack can adopt three different states:
• an empty stack,
• a filled stack,
• and a full stack.
55

Example: Stack
56

A possible test case
 Example: A stack accepting strings (type: string)
shall be tested.
 A possible test case with pre- and post-condition is
the following:
 Precondition: stack is initialized; state is "empty"
 Input: push ("hello")
 Expected result: stack contains "hello"
 Post-condition: state of the stack is "filled"
57

Test object for state transition
testing
1. In state transition testing the test object can be a
complete system with different system states
2. a class in an object-oriented system with different
states.
3. whenever the history leads to differing behavior, a
state transition test must be applied.
 Further test cases for the stack example
 Test case 1: initialize [empty], push [filled], push, push,
push [full].
 Test case 2: initialize [empty], push [filled], top, pop
[empty], delete.
58

Test criteria
 A state transition test should execute all specified
functions of a certain state at least once.
 In order to identify the necessary test cases, the
finite state machine is transformed into a transition
tree.
59

The Transition Tree
The transition tree is built from a transition diagram in the
following way:
I.The initial or start state is the root of the tree.
II.Transition from the initial state to a following state in the state
transition diagram, the transition tree receives a branch from its
root to a node, representing this next state.
III.The process for step 2 is repeated for every leaf in the tree
until one of the following two end-conditions is fulfilled:
1. The corresponding state is already included
2. The corresponding state is a final state, and no further
transitions to be considered.
60

Transition Tree For The Stack
Example
61

Wrong Usage Of The Functions
 The reaction of the state machine for wrong usage
must be checked
 e.g., to delete the stack while in "full" state
 This is a test of robustness to verify how the test
object reacts upon incorrect use.
 How?
 The transition tree should be extended by including
a branch for every function from every node.
62

Transition Tree For The Test For
Robustness
63

Test Cases
1. For a complete definition of a state-based test case the
following information is necessary:
 The initial state of the test object (component or system)
 The inputs to the test object
 The expected outcome or expected behavior
 The expected final state
1. For each expected transition of the test case the following
aspects must be defined:
 The state before the transition
 The initiating event that triggers the transition
 The expected reaction triggered by the transition
 The next expected state
64

Criteria
 Criteria for test intensity and for completion can also be
defined for the state transition testing:
1. Every state has been reached at least once
2. Every transition has been executed at least once
3. Every transition violating the specification has been
checked
 For highly critical applications
1. All combination of transitions
2. All transitions in any order with all possible states,
including multiple instances in succession
65

Decision Table Technique
4.1.4 Cause-Effect Graphing
01/12/18
66

Example: Cause-effect graph
analysis for an ATM
 withdrawing money at ATM
 The following conditions must be fulfilled[]
:
1. The bankcard is valid
2. The PIN must be correctly entered
3. The maximum number of PIN inputs is three
4. There is money in the machine, and in the account
 The following actions are possible at the machine:
1. Reject card
2. Ask for another PIN input
3. "Eat" the card
4. Ask for an alternate dollar amount
5. Pay the requested amount of money
67

Cause-effect Graph of the ATM
68

Decision Table To Design The Test
Cases
 The graph must be transformed into a decision table to design
the test cases
 Transform a graph into a table are as follows:
1. Choose an effect
2. Looking in the graph, find combinations of causes that
have this effect and combinations that do not have this
effect
3. Add one column into the table for every one of these
cause-combinations and the caused states of the
remaining effects
4. Check if decision table entries occur several times and, if
yes, delete them 01/12/184. Dynamic Testing/D.S.Jagli
69

Test with decision tables
Condition / Cause 1 2 3 4 5
Bankcard is valid N Y Y Y Y
PIN is correct - N N Y Y
3 incorrect PIN - N(exit) Y - -
Money available - - - N Y
Effect / Action
Reject card Y N N N N
Ask new PIN N Y N N N
Eat card N N Y N N
Ask new amount N N N Y N
Pay money N N N N Y01/12/184. Dynamic Testing/D.S.Jagli
70

 Test cases
 Every column is a test case
 Definition of the Test Completion Criteria
 execute every column in the decision table by at least one
test case.
 This verifies all sensible combinations of conditions and
their corresponding effects.
 The value of the technique
 errors can result from optimization of the decision table
71

For object
4.1.5. Use Case Testing
01/12/18
72

Use Case Testing
 UML widely used
 Identification of the requirements
 Showing an external view
 Pre- and postconditions
 Useful for system and acceptance testing
 Typical system use is tested
73

Use case diagram for ATM
74

Test Cases
 All the following information is necessary for
determining the test cases and must be available:
1. Start situation and preconditions
2. Other possible conditions
3. Expected results
4. Post-conditions
75

Use Case Testing …
 Definition of the test completion criteria
 A possible criterion is that every use case and every
possible sequence of use cases in the diagram is tested
at least once by a test case.
 The value of the technique
 Use case based testing is very useful for testing typical
user system interactions.
76

Further Black Box Techniques
 Further Black Box Techniques
1. Syntax test
2. Random test
3. Smoke test
 General Discussion of the Black Box Technique
1. Faults in specification not detected
2. Not required functionality is not detected
3. Verification of the functionality
77

4.2. White Box Testing Techniques
 What is White Box Testing?
 Execution-based testing that uses the program’s
inner structure and logical properties
 Code-based testing
 All code should be executed
78
01/12/18 78

Control Flow Graph
 Is Control flow graph necessary?
 Flow Graph helps us to analyze different types of coverage
 The graph makes it easier to specify in detail the control
elements
 Representation of CFG
 The statements are represented as nodes
 The control flows are represented as edges
 If sequences of unconditional statements appear in the
program are illustrated as one single node
 Conditional statements (IF, CASE) and loops (WHILE,
FOR) have more than one edge going out from them.
79
01/12/18 79

Example
program to finding max of given 3 numbers
int find−maximum(int i,int j,int k){
1. int max;
2. if(i>j) then
3. if(i>k) then
4. max=i;
5. else max=k;
6. else if(j>k)
7. max=j;
8. else max=k;
9. return(max); } 01/12/184. Dynamic Testing/D.S.Jagli
80

CFG
81
9
8754
63
2
1
T
T T
F
F
F

CFG
82
9
8754
63
2
1
a
b c
d e f g
h i j k

White Box Coverage Types
83

White Box Coverage Types
1. Statement Coverage: Every statement is executed
2. Branch Coverage: Every branch option is chosen
3. Path Coverage: Every path is executed
4. Test of conditions
i. branch condition testing
ii. branch condition combination testing
iii. condition determination testing
84

1. Statement Coverage
Every statement ( node) is
executed at least once
 In this test case the edges of
the graph must be traversed
in the following order:( 4
test cases )
1. a, b, d, h
2. a, b, e ,i
3. a, c, f ,j
4. a, c, g, k
01/12/18
85
9
8754
63
2
1
a
b c
d e f g
h i j k

Control flow of a program fragment
01/12/18
86
 Coverage of the nodes of
the control flow:
 a, b, f, g, h, d, e
 One test case is enough

Criteria
 The completion criteria for the tests can be clearly
defined:
 Statement coverage =
(number of executed statements / total number of
statements) *100%
 Statement coverage is also known as C0-coverage.
87

The Value of the Technique
(advantages)
1. Unreachable code can be detected
2. Empty ELSE-parts are not considered
3. Coverage is measured using test tools
88

2. Branch Coverage
 Features:
1. A more advanced criterion for white box testing
2. The execution of each decision.
3. Every decision is executed with both possible
outcomes (TRUE and FALSE )
4. It is also called as decision coverage
5. Empty ELSE-parts are considered
89

Test Cases
90
 All branches of the control
flow graph must be executed
1. a, b, f, g, h, d, e
 One test case is not enough
 Additional test cases
necessary
2. a, b, c, d, e
3. a, b, f, g, i, g, h, d, e
4. a, k, e

Definition of the Test Completion Criteria
 The degree of coverage for branch coverage is defined as
follows:
Branch coverage = (number of executed branches / total number
of branches) * 100%
 The Value of the Technique
1. More test cases are necessary
2. Tools often support determining coverage
3. Inadequate for object-oriented systems
4. It is used to detect uncalled methods or program parts (o
o systems)
91

3. Path Coverage
 Features:
 All possible paths through the test object
 Path coverage requires the execution of all
different paths through the test object.
 An execution path is a set of nodes and directed
edges in a flow graph that connects the start node
to a terminal node.
 The number of Basic paths is E – N + 2 (Linear
Complexity)
92

Test Cases
 Loop without repetition:
 a, b, f, g, h, d, e
 Loop with single return (i) and a
single repetition:
 a, b, f, g, i, g, h, d, e
 Usually a loop is repeated more
than once.
 a, b, f, g, i, g, i, g, h, d, e
 a, b, f, g, i, g, i, g, i, g, h, d, e
 a, b, f, g, i, g, i, g, i, g, i, g, h, d, e
 This shows that there is an
indefinite number of paths in the
control flow graph
 E – N + 2 10-8+2=4
01/12/18
93

4. Test of conditions
 Considering the complexity of combined
conditions
1. Branch condition testing
2. Branch condition combination testing
3. Condition determination testing
94

Branch condition testing
i. Branch condition testing
 The goal of the branch condition testing is that each
atomic (partial) condition in the test shall adopt the
values TRUE or FALSE.
 Definition of an atomic condition part
 x > 3 OR y < 5
 true OR false = true
 false OR true = True
95

ii. Branch Condition Combination
Testing
 All combinations of the logical values
 Eg:(x > 3, y < 5):
 Branch condition combination testing includes
statement and branch coverage
 All combinations are not always possible(keep
AND logic and check) 01/12/184. Dynamic Testing/D.S.Jagli
96
x=6 (T), y=3 (T), x>3 OR y<5 (T)
x=6 (T), y=8 (F), x>3 OR y<5 (T)
x=2 (F), y=3 (T), x>3 OR y<5 (T)
x=2 (F), y=8 (F), x>3 OR y<5 (F)

iii. Condition Determination Testing
 Restriction of the combinations
 (x>3, y<5). Four combinations are possible
 Changing a partial condition without changing the result
 Small number of test cases
97
1) x=6 (T), y=3 (T), x>3 OR y<5 (T)
2) x=6 (T), y=8 (F), x>3 OR y<5 (T)
3) x=2 (F), y=3 (T), x>3 OR y<5 (T)
4) x=2 (F), y=8 (F), x>3 OR y<5 (F)

Criteria
 If there are no complex condition expressions,
branch coverage can be seen as sufficient.
The Value of the Technique
 Complex conditions are often defect-prone
 A disadvantage of condition coverage is that it checks
Boolean expressions only inside a statement
98

Problem1:Design test cases for WBT
double calculate_price (
double baseprice, double specialprice,double extraprice, int extras, double
discount) {
double addon_discount;
double result;
if (extras >= 3)
addon_discount = 10;
else if (extras >= 5)
addon_discount = 15;
else addon_discount = 0;
if (discount > addon_discount)
addon_discount = discount;
result = baseprice /100.0*(100-discount)+ specialprice
+ extraprice/100.0*(100-addon_discount);
return (result);
99

Problem 2:Design test cases for WBT
A
DO
IF C THEN
IF D THEN
IF E THEN F
ELSE G
ELSE IF H THEN J
ELSE K
ELSE L
WHILE B
M
100

General Discussion of the White Box
Technique
1. Determine test intensity
2. Useful for lower test levels
3. Not existing source code" is not considered
Instrumentation and Tool Support
 Determination of the executed program parts
 Use tools
101

4.4 Intuitive and Experience Based
Test Case Determination
 Based on the skill, experience, and knowledge
102

Intuitive and Experience Based Test Case
Determination
 WHAT IS THIS?
1. Based on the skill, experience, and knowledge of the tester,
testing can be conducted.
2. The systematically identified test cases may be complemented
by intuitive test cases.
3. Intuitive testing can uncover faults overlooked by systematic
testing.
4. The tester selects test cases to uncover expected problems and
their symptoms.
5. A more systematic approach for this cannot be described.
6. This type of test case design is also called "error guessing"
and is used very often in practice. 01/12/184. Dynamic Testing/D.S.Jagli
103

Exploratory Testing
 If the documents, which form the basis for test design, are of
very low quality or do not exist at all, so-called "exploratory
testing" may help.
 The technique is also applicable when time is severely
restricted.
 The approach is mainly based on the intuition and experience
of the tester.
The approach in "exploratory testing“
• The test activities in exploratory testing are executed nearly in
"parallel".
• There is no application of a structured test process.
104

"Test charter”
 It makes sense to restrict exploratory testing to certain
elements of the program (certain tasks or functions).
 The test of a "charter" should not take more than one or two
hours of uninterrupted test time.
 When executing test charters, the following questions are of
interest:
 Why? With which goal, is the test run?
 What is to be tested?
 How? Which testing method should be used?
 Which problems should be found?
105

Main Features Of Exploratory
Testing
 The generic ideas of exploratory testing are:
 Results of one test case influence the design and execution of
further test cases.
 During testing, a "mental" model of the program under test is
created.
 The test is run against above model.
 Neither black box nor white box.
 Not to be used as first or only technique
 Using all knowledge
 Mostly successful in finding more defects
106

? ? ?
Thank you
01/12/18
107

4.dynamic analysis

More Related Content

What's hot (15)

Similar to 4.dynamic analysis (20)

More from VESIT/University of Mumbai (7)

Recently uploaded (20)

4.dynamic analysis