Software testing techniques
1 / 47

Software Testing Techniques - PowerPoint PPT Presentation

  • Uploaded on

Software Testing Techniques. Software Testing. Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user. Software Development Process. Tangible Product. Abstract Concept. Testing. Tries hard to demolish the software.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Software Testing Techniques' - vielka-tucker

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Software testing
Software Testing

Testing is the process of exercising a

program with the specific intent of finding

errors priorto delivery to the enduser.

Software development process
Software Development Process

Tangible Product




Tries hard to demolish the software

Software testing objectives
Software Testing Objectives software is always correct.

  • Uncovering different cases of errors

  • Needing minimum effort and time

  • Showing that software functions work according to specification

It cannot showabsence of errors or defects. It can only show that errors are present

Software testing principles

Customer thinks - most serious defect is not meeting his requirements

Software Testing Principles

All tests can be planned and designed before any coding begins

  • All tests should be traceable to customer requirements

  • Tests should be planned long before testing begins

  • The “pareto” principle applies to software testing

  • Exhaustive testing is not possible

  • To be most effective, testing should be conducted by a third party

80 % of errors originate from 20% of programs

Too many paths in a normal -size program

Who tests the software
Who requirements Tests the Software?


independent tester

Understands the system

Must learn about the system,

but, will test "gently"

but, will attempt to break it

and, is driven by quality

and, is driven by "delivery"

What is a good test
What is a requirementsGOOD Test?

Has a high probability of finding an error

It must not be redundant. Every test must have a different purpose

It should neither be too simple, nor too complex.

What testing shows
What Testing Shows requirements


requirements conformance


an indication

of quality

Testability requirements

  • Operability—it operates cleanly

  • Observability—the results of each test case are readily observed

  • Controlability—the degree to which testing can be automated and optimized

  • Decomposability—testing can be targeted

  • Simplicity—reduce complex architecture and logic to simplify tests

  • Stability—few changes are requested during testing

  • Understandability—of the design

Test case design
Test Case Design requirements

  • Design of test cases is as challenging asdesigning the software itself

  • A rich variety of test case design methods have evolved

  • Methods provide a systematic approach o testing

  • Methods provide a mechanism for that ensures the completeness of tests and high likelihood of finding an error

Software testing1
Software Testing requirements

black-box methods





White box testing
White Box Testing requirements

  • Close examination of procedural detail

  • Logical paths through the software are tested by providing test cases that exercise specific sets of conditions and/or loops

  • Status of the program is examined at various points to determine if the actual status matches the expected status

Does white box testing lead to 100 correct program
Does White Box Testing lead to 100% correct program? requirements

The answer is: No

It is not possible to exhaustively test every program path because the number paths is simply too large

Exhaustive testing
Exhaustive Testing requirements

loop < 20 X


There are10 possible paths! If we execute one

test per millisecond, it would take 3,170 years to

test this program!!

Selective testing
Selective Testing requirements

Selected path

loop < 20 X

Black box testing
Black Box Testing requirements

  • Know the specific function that the program is designed to perform

  • Test that each function is fully operational

  • Search for more errors in the functions

  • These tests are conducted at the software interface

  • Whether input is properly accepted and output is correctly produced

  • Integrity of external information (database) is maintained

  • Examines fundamental aspects of the system with little regard to internal logical structure

The attributes of both requirementsblack-box and white-box testing can be combined to provide an approach that validates the software interface and selectively ensures that the internal workings of the software are correct

White box testing1
White Box Testing requirements

  • Is also known as “Glass Box Testing”

  • Uses the control structure of the procedural design to derive test cases

If a= b then

do c


do v

Glass Box

White box testing2
White requirementsBox Testing

Guarantees that all independent paths within a module have been exercised at least once

Exercise all logical decisions on their true and false sides

Exercise all loops at their boundaries and within their operational bounds

Exercise internal data structures to ensure their validity

Test case design1
Test Case Design requirements

"Bugs lurk in corners

and congregate at

boundaries ..."

Boris Beizer


to uncover errors


in a complete manner


with a minimum of effort and time

Why cover
Why Cover? requirements

logic errors and incorrect assumptions

are inversely proportional to a path's

execution probability

we often


that a path is not

likely to be executed; in fact, reality is

often counter intuitive

typographicalerrors are random; it's

likely that untested paths will contain


Why need white box testing
Why need requirementsWhite-box testing?

  • Logic errors occur more frequently in the less probable paths of execution

  • Everyday processing tends to be well understood while “special case “ processing tends to fall into cracks

  • We often believe that a logical path is not likely to be executed when , in fact it may be executed on a regular basis

  • Typos are random. It is as likely that a type will exist on an obscure logical path as on a mainstream path.

White box testing3
White-Box Testing requirements

... our goal is to ensure that all

statements and conditions have

been executed at least once ...

Basis path testing
Basis Path Testing requirements

  • It is white-box testing technique

  • Proposed by Tom Macabe

  • Derives a logical complexity measure

  • Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least once during testing

  • Uses flow-graph notation

  • Each structured construct has corresponding flow graph symbol

Structured constructs
Structured Constructs requirements








Repeat until



Flow graph symbols
Flow Graph Symbols requirements






Flow graph symbols1
Flow Graph Symbols requirements

  • Each circle is called a flow graph node , represents one or more procedural statements

  • A sequence of process boxes and a decision diamond can map into a single node

  • An edge (arrow) must terminate at a node

  • Areas bounded by edged and nodes are called regions

  • Area outside graph is also a region

Flow graph for compound conditions
Flow Graph for Compound Conditions requirements


  • A compound condition occurs when one or more Boolean operators (AND,OR) is present in a conditional statement

  • Separate node is created for each condition

  • Each condition node is known as predicate node

  • Each predicate node has two or more edges leaving it





If a or b then procedure x


procedure y


Cyclomatic complexity
Cyclomatic Complexity requirements

  • Very useful software metric

  • Foundation on graph theory

  • Quantitative measure of the logical complexity of the program

  • It defines the number of independent paths in the basis set of a program

  • Provides s with an upper bound for the number of tests to be conducted

  • Ensures that all statements have been executed at least once

Cyclomatic complexity1
Cyclomatic Complexity requirements

A number of industry studies have indicated

that the higher V(G), the higher the probability

or errors.



modules in this range are

more error prone

Computation of cyclomatic complexity v g for flow graph g

There are requirementsthree ways:

Computation of Cyclomatic Complexity V(G) for flow - graph G

V(G) = P+1


P - no. of predicate nodes in G

V(G) = E - N + 2


W - no. of edges in G

N - no. of nodes in G

V(G) = R


R- no. of regions in G

Given flow-graph has 4 regions

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

V(G) = 3 + 1 = 4

Independent path
Independent Path requirements

  • Any path through the program that introduces at least one new set of processing statements or a new condition

  • Must move along at least one edge that has not been traversed before the path is defined

  • Each path introduces a new edge

  • There are Four paths for the given example:

    • Path 1: 1-11

    • Path 2: 1-2-3-4-5-10-1-11

    • Path-3: 1-2-3-6-8-9-10-1-11

    • Path 4: 1-2-3-6-7-9-10-1-11

Basis path testing1

1 requirements








Basis Path Testing

Next, we derive the

independent paths:

Since V(G) = 4,

there are four paths

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

Finally, we derive test

cases to exercise these


Deriving test cases
Deriving Test Cases requirements

  • Using the code as the foundation , draw a corresponding flow graph

  • Determine the cyclomatic complexity of the flow graph

  • Determine a basis set of linearly independent paths

  • Prepare test cases that will force execution of each path in the basis set

  • Execute each test case and compared to expected results

  • Some paths cannot be tested independently and must be tested as part of another path

Condition testing
Condition Testing requirements

  • It is a design method that exercises the logical conditions (Consisting of arithmetic, relational and Boolean expressions and operators) in a program module

  • Types of error found in a condition:

    • Boolean operator error

    • Boolean variable error

    • Boolean parenthesis error

    • Relational operator error

    • Arithmetic expression error

Condition testing1
Condition Testing requirements

  • Branch Testing

    • For a compound condition C, the true and false branches of C and every simple condition in C need to be executed at least once

  • Domain Testing

    • Requires three or four tests for a relational expression

    • To detect errors in E1<relational-operator>E2

      • three tests are required to detect error in the operator

      • putting as minimum possible different values in E1 and E2 will help to detect errors in E1and E2

Bro testing
BRO Testing requirements

  • All relational operators and boolean variables must occur only once

  • Uses condition constraint for a condition C which is defined as (D1, D2, …Dn) where Dispecifies thea constraint on he outcome of ith condition of C

  • Boolean variables have constraint value True or False

  • For relational expression symbols <,>, = are used to specify the conditions

Bro testing examples
BRO Testing - Examples requirements

Example 1: B1 & B2

C1= (D1,D2) = {(t,t),(t,f),(f,t)}

Example 2: B1 & (E3=E4)

C2= (D1,D2) = {(t,=),(t,>),(t,<),(f,=)}

Example 3: (E1 > E2) & (E3=E4)

C2= (D1,D2) = {(>,=),(<,=),(>,>),(>,<),(=,=)}

Dataflow testing
Dataflow Testing requirements

  • Selects test paths according to the location of definitions and uses of variables in the program (S-statement no.)

  • DEF(S) = {X| statement S contains a definition of X} USE(S) = (X| statement S contains a use of X} Assume

  • For if or loop statement DEF set is always empty

  • The definition of var X at S is said to be live at statement S’ if the path S-S’ contains no other definition of X

  • A definition-use chain of var Xis of the form [X,S,S’] where X is DEF(S) and USE(S’) and X is live at S’.

Du testing
DU Testing requirements

  • Every DU chain should be covered at least once

  • Useful for programs with nested if and loop statements

  • Effective for error-detection

  • Selecting test-paths is quite difficult

  • Does not guarantee all branches of a program (e.g. if statement with no else statement and no definition in the then part.

Du testing1
DU Testing requirements

proc x


do while C1

if C2


if C4

then B4;

else B5;



if C3

then B2;

else B3;





end proc;

Var X is defined in the last statement of blocks B1, B2, B3, B4, B5 and used in the first statements of B2, B3, B4, B5, B6

There are 25 DU chains of var X

We need to cover only five paths from each B1, B2, B3, B4, B5 to B6

Loop testing
Loop Testing requirements

  • Loops are he cornerstone of vast majority of all software

  • Focuses exclusively on the validity of loop constructs

  • Four different classes of loops are defined:

    • Simple loops

    • Nested loops

    • concatenated loops

    • unstructured loops

Loop testing1
Loop Testing requirements









Simple loops
Simple Loops requirements

Set of Tests

  • Skip the loop entirely

  • Only one pass through the loop

  • Two passes through the loop

  • M passes through the loop where m < n (n – max no. pf allowable passes)

  • N-1, n, n+1 passes throughthe loop

Nested loops
Nested Loops requirements

Number of possible test is impractically large if simple loop approach is adopted.

  • Start at the innermost loop. Set allother loops to minimum value

  • Conduct simple loop test for the innermost loop while outer loops have the minimum loop counter

  • Work outward, conducting tests for the next loop , keeping outer loops at minimum value and nested loops at typical values

  • Continue until all loops have been tested

Concatenated loops
Concatenated Loops requirements

  • Simple loop approach can be adopted if each of the loops is independent of the others

  • If loop counter value of one loop is used as the initial loop counter value of another, then the loops are not independent. In such cases nested loop approach should be adopted