Software Testing Methodologies Student Notes

Unit 1
STM
Software Testing Methodologies

Unit1-Introduction
1. The Purpose of Testing

2. Dichotomies

3. A model for Testing

4. Taxonomy of Bugs

Purpose of Testing:

 Software testing is an activity that is used to evaluate the capabilities of a system and
determine if it is accordance with the specification

 Testing is the process of executing a program with the intent of finding errors

 Testing generally performed for the following purposes

1) Software Quality assurance

2) Verification and Validation
3) Reliability Estimation
Goals for Testing

 Goals for Testing

Bug prevention – Primary goal

Bug discovery – Secondary goal

 Bug prevention – Designing Tests is considered as the best bug preventer or. it means
that if a test is properly designed it is easy to detect and prevent the bugs. Before coding itself. If
testing is performed at every stage of software development we can eliminate most of the bugs
would be discovered and prevented in design phase itself.

 Bug discovery: It is performed when the primary goal fails to prevent the bugs.. A single
bug can have many reasons. Therefore just by determining that the PG is incorrect does n’t
reveal the discovery of bugs. each symptom can be revealed only by performing many small
detailed tests on each of the individual symptoms.

Phases in Tester’s mental life:

Phases in Tester’s mental life:

 Phase 0: There is no difference between testing and debugging

 Phase 1:The POT is to show that the software is works

 Phase 2:The POT is to show that the software does not works

 Phase 3: The POT is reduce the perceived risk of not working to an acceptable level
 Phase 4: It is mental discipline that results in low risk software without much testing effort

Sri Sivani college of Engineering 1

Software Testing Methodologies Student Notes

Unit 1

Principles of test case design

 Principles of test case design

1) Effective fragmentation of available tests

2) Accurate Testing Technique for each test module

3) Specifying the correct level of details for the Test

Why the testing isn’t everything ?

 Why the testing isn’t everything?

Before we going for testing, we must first review, inspect, read, do walkthroughs and then test

The major methods in decreasing order of effectiveness as follows:

 Inspection Methods
 Design style
 Static Analysis Methods
 Languages
 Design Methodologies and Development Environment

Dichotomies
 Testing versus Debugging
 Function versus Structure
 Designer versus Tester
 Modularity versus Efficiency
 Small versus Large
 Builder versus Buyer

Testing Versus Debugging:

The purpose of testing is to show that a program has bugs. The purpose of debugging is find
the error that led to the program’s failure and to design and implement the program changes that
correct the error. Debugging usually follows testing, but they differ as to goals, methods, and
most important, psychology:

1. Testing starts with known conditions, uses predefined procedures, and has
predictable outcomes Debugging starts from possibly unknown initial conditions, and the
end cannot be predicted, except statistically.
2. Testing can and should be planned, designed, and scheduled. The procedures for,
and duration of, debugging cannot be so constrained.
3. Testing is a demonstration of error or apparent correctness. Debugging is a deductive
process.
4. Testing proves a programmer’s failure. Debugging is the programmer’s vindication.

Sri Sivani college of Engineering 2

Software Testing Methodologies Student Notes

Unit 1
6. Much of testing can be done without design knowledge. Debugging is impossible
without detailed design knowledge.
7. Testing can often be done by an outsider. Debugging must be done by an insider.

Function versus Structure (Black box/white box)

Tests can be designed from a functional or a structural point of view. In functional testing the
program or system is treated as a black box. It is subjected to inputs, and its outputs are verified
for conformance to specified behavior. The software’s user should be concerned only with
functionality and features, and the program’s implementation details should not matter. Functional
testing takes the user’s point of view.

Structural testing does look at the implementation details. Such things as programming style,
control method, source language, database design, and coding details dominate structural
testing;

The Designer versus the Tester

If testing were wholly based on functional specifications and independent of implementation

details, then the designer and the tester could be completely separated. Conversely, to design a
test plan based only on a system’s structural details would require the software designer’s
knowledge, and hence only she could design the tests

The Builder versus the Buyer

Most software is written and used by the same organization. Unfortunately, this situation lost the
accountability. Many organizations today recognize the virtue of independent software
development and operation because it leads to better software, better security, and better testing.

The builder, who designs for and is accountable to, the buyer, who pays for the system in the
hope of profits from providing services,

Modularity Versus. Efficiency

A module is a small component of a system. The smaller the component, the easier it is to
understand; but every component has interfaces with other components, and all interfaces are
sources of confusion. The smaller the component, the likelier are interface bugs. Large
components reduce external interfaces but have complicated internal logic that may be difficult or
impossible to understand

 Tests
 Tests are formal procedures. Inputs must be prepared, outcomes predicted, tests
documented, commands executed, and results observed; all these steps are subject to error..

Testing and Levels

Sri Sivani college of Engineering 3

Software Testing Methodologies Student Notes

Unit 1
Unit, Unit Testing—. Unit testing is the testing we do to show that the unit does not
satisfy its functional specification and/or that its implemented structure does not match
the intended design structure
Component, Component Testing—Component testing is the testing we do to show
that the component does not satisfy its functional specification and/or that its

implemented structure does not match the intended design structure. When our tests
reveal such problems, we say that there is a component bug.
Integration, Integration Testing—. Integration testing is testing done to show that
even though the components were individually satisfactory the combination of
components is incorrect or inconsistent.
System, System Testing—A system is a big component System testing concerns
issues and behaviors that can only be exposed by testing the entire integrated system or
a major part of it. System testing includes testing for performance, security,
accountability, configuration sensitivity, start-up, and recovery.

A model for Testing

 Testing is applied to anything from subroutines to systems that consist of millions of

statements
 A real-world context characterized by the following model project
 Application
 Staff
 Schedule
 Specification
 Acceptance Test
 Personnel
 Standards
 Objectives
 Source
 History

Overview

 The process starts with a program embedded in an environment, such as a computer, an

operating system, or a calling program. This understanding leads us to create three models:
 a model of the environment,
 a model of the program,
 a model of the expected bugs.

 From these models we create a set of tests, which are then executed. The result of
each test is either expected or unexpected.

 If unexpected, it may lead us to revise the test, our model or concept of how the program
behaves, our concept of what bugs are possible, or the program itself. Only rarely would we
attempt to modify the environment.

Sri Sivani college of Engineering 4

Software Testing Methodologies Student Notes

Unit 1

Importance of bugs:

Importance($)= frequency* (correction cost + Installation cost +consequential cost)

Consequences of Bugs:

 Mild
 Moderate
 Annoying
 Disturbing
 Serious
 Very serious
 Extreme
 Intolerable
 Catastrophic
 Infectious

A TAXONAMY (classification of) of BUGS

 Requirements, Features, and Functionality Bugs
 Structural Bugs
Control and sequence of bugs
Logic Bugs
Processing Bugs
Initialization Bugs
 Data Bugs
Static data: does not change the value in the PG execution
Dynamic data: does change the value in the PG execution
 Coding Bugs
 Interface, Integration, and System Bugs
External interface bugs
Internal interface bugs
Operating system bugs
 Test and Test design bugs
Remedies for test bugs:

 Test debugging
 Test quality assurance
 Test execution automation
 Test design automation

Sri Sivani college of Engineering 5

Software Testing Methodologies Student Notes

Unit 1

Sri Sivani college of Engineering 6

Software Testing Methodologies Student Notes

Unit 1

What is meant by statement coverage (C1) and branch coverage (C2)? Explain with
an example, how to select enough paths to achieve C1+C2.

 A path through a program is a sequence of instructions or statements that starts at

an entry (or junction, or decision) and ends at another exit (or junction, or decision).
 Paths consist of segments and the smallest segment is a link i.e., a single process that
lies between two nodes
 The length of a path is by the number of nodes traversed
 Path segment is a succession of consecutive links that belongs to some path

Fundamental Path Selection Criteria states that

exercise every

1. path from entry to exit.

2. statement or instruction at least once.
3. branch and case statement, in each direction, at least once.

Path–Testing Criteria

 Any testing strategy based on paths must at least both exercise every instruction and
take branches in all directions.
 A set of tests that does this is not complete in an absolute sense, but it is complete in
the sense that anything less must leave something untested.
 There are three different testing criteria or strategies out of a potentially infinite
family of strategies.
1. Path Testing
2. Statement Testing
3. Branch Testing

Statement Coverage
Execute all statements in the program at least once under some test. If we
do enough tests to achieve this, we are said to have achieved 100%
statement coverage (C1) This is the weakest criterion in the family: testing
less than this for new software is unconscionable and should be
criminalized.

Sri Sivani college of Engineering 7

Software Testing Methodologies Student Notes

Unit 1
Branch Coverage
Branch Testing (P2) Execute enough tests to assure that every branch
alternative has been exercised at least once under some test. If we do
enough tests to achieve this prescription, then we have achieved 100%
branch coverage (C2). For structured software, branch testing and
therefore branch coverage strictly includes statement coverage.

Example

 You must pick enough paths to achieve C1 + C2.

 The question of what is the fewest number of such paths is interesting to the
designer of test tools that help automate path testing
 As an example of how to go about selecting paths take any simple graph
 Start at the beginning and take the most obvious path to the exit—it typically
corresponds to the normal path.
 Then take the next most obvious path (CHOOSE YOUR OWN/ANY EXAMPLE),

Other Suggesions are

 Draw the control flowgraph on a single sheet of paper.

 Make several copies—as many as you’ll need for coverage (C1 + C2) and several
more.
 Highlight the paths bold letters
 Continue tracing paths until all lines on the master sheet are covered, indicating
that you appear to have achieved C1 + C2.

As you trace the paths, create a table that shows the paths, the coverage status of each process, and
each decision

Suhrit Answers for

What is meant by a Loop? State and explain various kinds of Loops with suitable
examples. Also discuss how to select optimal paths for C1+C2.(Statement coverage +
Branch coverage)

Loop
Set of statements repeated for specified number of times or until it meets
specific condition is called as a Loop. For example print statement which is
included in a for loop executes n number of times based on condition in for
loop. There are four types of loops 1. Single Loop 2. Nested Loop 3.
Concatenated Loop 4. Horrible Loop

Single Loop
A simple loop that executes based on the following cases are considered as single loop.

Sri Sivani college of Engineering 8

Software Testing Methodologies Student Notes

Unit 1
Case 1 Single Loop, Zero Minimum, N Maximum, No Excluded Values
for(i=0;i<=10;i++)
{
printf(“%d”,i); // loop begins with 0 and ends with 10
}
Case 2 Single Loop, Nonzero Minimum, No Excluded Values
for(i=10;i<=20;i++)
{
printf(“%d”,i); // loop begins with 10 and ends with 20
}
Case 3 Single Loops with Excluded Values
for(i=1;i<=10;i+=2)
{ printf(“%d”,i); //loop excludes even numbers
}

Testing Strategies on Single Loop

 Try one less than the expected minimum. Check boundary of control variable
 The minimum number of iterations.
 One more than the minimum number of iterations.
 Once, unless covered by a previous test.
 Twice, unless covered by a previous test.
 A typical value.
 One less than the maximum value.
 The maximum number of iterations.
 Attempt one more than the maximum number of iterations.

Nested Loop
Loop with in another loop can be called as Nested loop as like…
for(i=1;i<=10;i+=2)
{
for(j=1;j<=10;j+=2)
{
printf(“%d”,i+j);
}
}

General Testing Strategies on Nested Loops

 Start at the innermost loop. Set all the outer loops to their minimum values.
 Test the minimum, minimum + 1, typical, maximum – 1, and maximum for the
innermost loop.
 If you’ve done the outermost loop, GOTO step 5, otherwise move out one loop and
set it up as in step 2—with all other loops set to typical values.
 Continue outward in this manner until all loops have been covered.
 Do the five cases for all loops in the nest simultaneously

Concatenated Loops

Sri Sivani college of Engineering 9

Software Testing Methodologies Student Notes

Unit 1
 Concatenated loops fall between single and nested loops with respect to test cases.
 Two loops are concatenated if it’s possible to reach one after exiting the other while
still on a path from entrance to exit.
 If the loops cannot be on the same path, then they are not concatenated and can be
treated as individual loops.

Horrible Loops

 The thinking required to check the end points and looping values for intertwined
loops appears to be unique for each program.
 It’s also difficult at times to see how deeply nested the loops are, or indeed whether
there are any nested loops.
 The use of code that jumps into and out of loops, intersecting loops, hidden loops,
and cross–connected loops, makes iteration
 value selection for test cases very difficult, an awesome and ugly task, which is
another reason such structures should be avoided.

To get optimal paths for C1+C2

 You must pick enough paths to achieve C1 + C2.

 The question of what is the fewest number of such paths is interesting to the
designer of test tools that help automate path testing
 As an example of how to go about selecting paths take any simple graph
 Start at the beginning and take the most obvious path to the exit—it typically
corresponds to the normal path.
 Then take the next most obvious path (CHOOSE YOUR OWN/ANY EXAMPLE),

Other Suggesions are

 Draw the control flowgraph on a single sheet of paper.

 Make several copies—as many as you’ll need for coverage (C1 + C2) and several
more.
 Highlight the paths bold letters
 Continue tracing paths until all lines on the master sheet are covered, indicating
that you appear to have achieved C1 + C2.

As you trace the paths, create a table that shows the paths, the coverage status of each process, and
each decision

Discuss about assignment blindness, and equality blindnesss of predicates.

 Testing blindness is a pathological situation in which the desired path is achieved for
the wrong reason.
 It can occur because of the interaction of two or more statements that makes the
buggy predicate work despite its bug
 There are three types of blindness, they are

Sri Sivani college of Engineering 10

Software Testing Methodologies Student Notes

Unit 1
1. Assignment blindness
2. Equality blindness
3. Self–blindness

Assignment Blindness

 Assignment blindness occurs when the buggy predicate appears to work correctly.
 Specific value chosen for an assignment statement works with both the correct and
incorrect predicate.
 For example:
Correct Bug
testX=20; testX=20;
…….. …….
if(testY>0) if(testX+testY>0)
{ {

} }

Equality Blindness

 Equality blindness occurs when the path selected by a prior predicate results in a
value that works both for the correct and buggy predicate.
 For example:
Correct Bug
if(testY==20) if(testY==20)
…….. …….
if(testX+testY>30) if(testX>10)
{ {

} }

Explain the terms achievable and unachievable paths.

 If you can find a solution, then the path is achievable.

 If you can’t find a solution to any of the sets of inequalities the path is unachievable.
 Based on the below steps check the possibility of solution
o We want to select and test enough paths to achieve a satisfactory notion of
test completeness such as C1 and/or C2.
o Extract the program’s control flowgraph and select a set of tentative
covering paths.
o For any path in that set, interpret the predicates along the path as needed
to express them in terms of the input vector.

Sri Sivani college of Engineering 11

Software Testing Methodologies Student Notes

Unit 1
o Trace the path through, multiplying (boolean) the individual compound
predicates to achieve a boolean expression.
o Multiply out the expression to achieve a sum–of–products form
o Each product term denotes a set of inequalities that, if solved, will yield an
input vector that will drive the routine along the designated path.
o Solve any one of the inequality sets for the chosen path and you have found
a set of input values for the path.
 The act of finding a set of solutions to the path predicate expression is called path
sensitization.

Sri Sivani college of Engineering 12