Software Testing Fundamentals

• There are two general approaches for software testing

• Black Box Testing

- proper functioning of the s/w is tested
- whether the s/w accepts the i/p properly & generates
proper o/p.
- external interfaces, external data & information – is tested.

• White Box Testing

- procedural details are closely examined
- internals of s/w are tested.
- i.e. internal structures, logic paths, control flows,
- data flows, internal data structures, conditional loops etc.
 White Box Testing

1. Basis Path Testing

2. Control Structure Testing
White-Box Testing

... our goal is to ensure that all

statements and conditions have
been executed at least once ...
 1. Basis Path Testing
• Every execution path will be tested at least once

• Steps –

1. Design flow graph for the program or a component

2. Calculate cyclomatic complexity

3. Select a basis set of path

4. Generate test cases for this paths

4
 1. Design flow graph
for the program or a component
• Graphical representation of control flow of the
program

• Contains –

- Nodes – represents one or more procedural

statements

- Edges – represent control flow

- Regions – areas bounded by nodes and edges

 2. Calculate Cyclomatic Complexity
• There are three ways to calculate CC

1. CC = Total number of regions in the flow graph

2. CC = E – N + 2
= number of edges – number of nodes + 2

3. CC = number of predicate nodes + 1

6
Basis Path Testing

compute the cyclomatic

complexity:

number of simple decisions + 1

or

number of enclosed areas + 1

In this case, V(G) = 4

7
3. Select Basis set of Path

Next, we derive the

2
independent paths:

Since V(G) = 4,
3 there are four paths
4
5 6 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
7 Finally, we derive test
cases to exercise these
paths.
8
 4. Generate Test Cases For This Paths
Test Test Test Test steps Test Test Defe
case case case case priorit ct
id name descript status y seve
step Expected Actual
ion (pass rity
/fail)
1

5
 What is Test case?
• A test case is a document, which has -
- a set of test data, preconditions,
- expected results and post conditions,

• developed for a particular test scenario

- in order to verify compliance against a specific
requirement.

• Test Case acts as the starting point for the test execution,
- and after applying a set of input values,
- the application has a definitive outcome and
- leaves the system at some end point or also known as
execution post condition.
 Format of Standard Test Cases
(Below is format of a standard login Test case )

Test
Case Actual
Test Expected Pass
ID Test Steps Test Data Result
Scenario Results /Fail
s

Check
1.Go to site
Custome Userid =
http://demo.guru99.com User should As
r Login guru99
TU01 2.Enter UserId Login into Expect Pass
with Password
3.Enter Password application ed
valid = pass99
4.Click Submit
Data
Check
1.Go to site
Custome Userid = User should
http://demo.guru99.com As
r Login guru99 not Login
TU02 2.Enter UserId Expect Pass
with Password into
3.Enter Password ed
invalid = glass99 application
4.Click Submit
Data
• Below are the standard fields of sample test case template:

• Test case ID:

- Unique ID for each test case.
- Follow some convention to indicate types of test.
- E.g. ‘TC_UI_1’ indicating ‘user interface test case #1’.

• Test priority (Low/Medium/High):

- This is useful while test execution.
- Test priority for business rules and functional test cases can be medium or
higher
- whereas minor user interface cases can be low priority.
- Test priority should be set by reviewer.

• Module Name – Mention name of main module or sub module.

• Test Designed By: Name of tester

• Test Designed Date: Date when wrote

• Test Executed By:

- Name of tester who executed this test. To be filled after test execution.
• Test Execution Date: Date when test executed.

• Test Title/Name:
- Test case title.
- E.g. verify login page with valid username and password.

• Test Summary/Description: Describe test objective in brief.

• Pre-condition:
- Any prerequisite that must be fulfilled
- before execution of this test case.
- List all pre-conditions in order to successfully execute this test case.

• Dependencies:
- Mention any dependencies on other test cases or test requirement.
 2. Control Structure Testing

• Condition testing —
- a test case design method
- that exercises the logical conditions
- contained in a program module
- ex. Testing of Loops, Branching, Switching statements

• Data flow testing —

- selects test paths of a program
- according to the locations of definitions
- and uses of variables in the program
- ex. Variable declaration & scope, data types used, parameter
passing using functions, etc.
Loop Testing

Simple
loop
Nested
Loops

Concatenated
Loops Unstructured
Loops
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), n, and (n+1) passes through
the loop
where n is the maximum number
of allowable passes
 Loop Testing – Nested Loops
1. Start at the innermost loop

2. Set all outer loops to their minimum iteration

parameter value
- Test the min+1, typical, Max-1 & max , for the
innermost loop

3. Move out one loop & set it up – as in step 2

- holding all other loops at typical value
- continue this step, until the outermost loop is
tested.
Black Box Testing
• Also called – behavioral testing

• Functional requirements of the software are tested.

• Uncovers following type of errors –

- incorrect or missing functions
- interface errors
- errors in data structure
- performance errors
- initialization or termination errors
Black-Box Testing

requirements

output

input events
 Black Box Testing - Techniques
1. Equivalence Partitioning

2. Boundary Value Analysis

3. Graph Based Testing

 1. Equivalence Partitioning
• Divides
- input domain into classes of data

• From this data

- test cases can be derived

• Equivalence classes
- are evaluated for given input condition

• Equivalence class represents

- a set of valid or invalid states
- for input conditions

24
1. If an input condition specifies a range,
- one valid and two invalid equivalence classes
- are defined

– Input range: 1 – 10

– Eq classes: {1..10}, {x < 1}, {x > 10}

2. If an input condition requires a specific value,

- one valid and two invalid equivalence classes
- are defined

– Input value: 250

– Eq classes: {250}, {x < 250}, {x > 250}
3. If an input condition specifies a member of a set,

- one valid and one invalid equivalence class

- are defined
– Input set: {-2.5, 7.3, 8.4}
– Eq classes: {-2.5, 7.3, 8.4}, {any other x}

4. If an input condition is a Boolean value,

• one valid and one invalid class are defined

– Input: {true condition}
– Eq classes: {true condition}, {false condition}
 2. Boundary Value Analysis
• A greater number of errors occur
- at the boundaries of the input domain
- rather than in the "center“

• Is - a test case design method

- that complements equivalence partitioning

– It selects test cases at the edges of a class

– It derives test cases from both the input domain and output domain
1. If an input condition specifies a range

- bounded by values a and b,

- test cases should be designed with values a and b
- as well as
- values just above and just below a and b

- ex. Integer D with input condition  [-2,10]

test values  -3,-2,-1 9,10,11,

2. If an input condition specifies a number of values,

- test case should be developed
- that exercise
- the minimum and maximum numbers.

- Values just above and just below

- the minimum and maximum are also tested

- ex. Integer E with input condition : {2,7,100,102}

test values  1,2,3 101,102,103
 3. Graph Based Testing
• Objects and their relationships are tested,

• By Creating –

• Graph of
- objects and their relationships,

• Node weight represents –

- properties of an object

• Link weight – represents –

- properties of relationships of the objects
 Graph-Based Methods
object Directed link object
#1 (link weight) #2
To understand
• the objects
that are modeled in Undirected link
Node weight
(value
software and )
• the relationships Parallel links
object
that connect these #
objects 3

(a)
Here - “objects” can be
 data objects,
traditional components new menu select generates document
(modules), and object- file (generation time  1.0 sec) window
oriented elements of
computer software.
allows editing
of Attributes:
is represented as
contains
document background color: white
tex text color: default color
t or preferences

(b)
 object Directed link object
#1 (link weight) #2

Node weight
Undirected link
(value
)
Parallel links
object
#
3

(a)

new menu select generates document

file (generation time  1.0 sec) window

allows editing
of Attributes:
is represented as
contains
document background color: white
tex text color: default color
t or preferences

(b)