Post on 04-Apr-2018
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 1/32
TESTING
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 2/32
NEED OF TESTING
• The aim of program testing is to identify alldefects in a program.
• Software testing is needed to verify and validate
that the software that has been built to meet thespecifications.
• Testing ensures that what you get in the end iswhat you wanted to build.
• Testing enhances the integrity of a system bydetecting deviations in design and errors in thesystem.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 3/32
Basic concepts
• Testing a program involves providing the program withset of test inputs and observing the program behavesas expected.
• An error is a mistake commited by the development
team during development phase.(a fault, a bug, adefect)
• A test case is a triplet[I,S,O]
• A test suite is the set of all test cases with which a
given software tested.• While verification is concerned with phase
containment of errors, the aim of validation is to makefinal product error free.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 4/32
Levels of testing
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 5/32
1)Unit testing:
• It is referred as testing in the small.
• Unit testing is undertaken after a module has been codedand reviewed.
• During unit testing, all the individual components of a
program are tested .• Requires knowledge of the internal program design and
code.
• Done by Programmers (not by testers).
Methods for testing are White Box testing techniques,TestCoverage techniques
.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 6/32
2)Integration testing:
• After testing individually, the units are slowly
integrated and tested after each step of
integration
• Developers does this type of testing.
• Methods of testing are: White and Black Box
techniques
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 7/32
3)System testing:
Finally, the fully integrated system is tested.
Integration testing and system testing are known
as testing in the large.
• Objective is To perform inter-system test and
to check the transaction flow
•
To demonstrate that the system performs bothfunctionally and operationally as specified
System testers do this kind of test.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 8/32
4) Systems Integration Testing
• To test the co-existence of products and
applications that are required to perform
together in the production-like operational
environment
• The system connected with the network in
organisation and make an environment where
the project can be run and test it
• System Testers do this kind of test.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 9/32
5) Acceptance Testing
• The objective is To verify that the system
meets the user requirements
• It is done in the users environment
• User does this kind of testing
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 10/32
Testing methods/techniques
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 11/32
1)Black box testing:
This testing methodology looks at what are the
available inputs for an application and what
the expected outputs are that should result
from each input.
• It is solely based on an analysis of the
input/output behaviour(functional behaviour)
• This testing is also known as functional testing
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 12/32
2)White box testing:
white-box testing enables you to see what is
happening inside the application.
• It means while designing test cases for white
box testing ,one needs to have a thorough
knowledge of the internal structure of a
program.
• It is also known as structural testing.
• It is based on analysis of the code.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 13/32
Testing activities
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 14/32
code
Design
document
SRS
document
Design test
suite Test suite
Run testand
check
result
Failure list
Debug
programError listCorrected
errors
Corrected
programs
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 15/32
Design test cases
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 16/32
Design test cases In Black box testing
• There are two approaches to design black box testcases
1)Equivalence class partitioning
Here the domain of input values to the program under
test is partitioned into a set of equivalence classes andtake one input from each class to form test case
General guidelines for designing the equivalence classes:
-if the range of values specified in the program, then one
valid and two invalid classes need to be identified.--if the input data assumes values from set of discrete
members of some domain, then one valid class andone invalid class should be defined.(eg, ABCD)
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 17/32
2)Boundary value analysis:
Boundary value analysis-based test suite design
involves designing test cases using the valuesat the boundaries of different equivalnceclasses.
It is done to find out the error related to the
<;>;>=;<= etc.
Here first the equivalence classes is identifiedonly if it contains range of values. And
boundary values are included in the test case.If there are not a range of values ,then boundary
value test case can’t be defined.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 18/32
problem
1)For software that computes the square root
of an integer that can assume values in the
range of 0 to 5000. determine the equivance
and boundary value analysis
2)Design equivalence class for a function that
reads a character string of size less than five
characters and displays whether it ispalindrome.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 19/32
Design test cases In White box testing
• Large no. of white box testing strategies exists
to design test cases.
• Each strategies design test cases based on the
analysis of source code.
• Ex:
1)statement coverage strategy
2)branch coverage strategy
3)path coverage
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 20/32
Statement coverage strategy
• It aims to design test cases so as to execute
every statement in a program at least once.
• Here for upper control loop, it needs to be
false. And for inner control loop, it needs to be
made true and false.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 21/32
Branch coverage strategies
• It aims at designing test cases so as to make
each branch condition in a program to assume
true and false values in turn.
• It is stronger testing than statement coverage
testing
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 22/32
Path coverage strategy
• It aims at designing test cases such that alllinearly independent paths(basis path) In theprogram are executed at least once.
• Before identifying the basis path, tester needto have the knowledge of CFG
• CFG is a control flow graph. It describes how
the control flows trough the program.• CFG for sequence, selection and iteration.
• Specify the nodes and edge in the CFG.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 23/32
• Find the no of linear independent graph in theprogram using Mccabe’s Cyclomatic complexity
metricV(G)=E-N+2
• Then find out the path from source to destination.
each path should be different from others.meanssame nodes should not be in other path.inaddition new node should be there.
And specific value is given according to path
Example:path1= (1,6) value=(3,3)
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 24/32
Debugging approches
After a failure has been detected, it is necessary tofirst identify the program statements that are inerror and are responsible for the failure, the errorcan then be fixed.
Approaches:1)backtracking:
fairly common approach
in this approach, beginning from the statement atwhich an error symptom has been observed, thesource code is traced backwards until the error isdiscovered.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 25/32
2)Cause elimination method:
In this approach, once a failure is observed, the
symptoms of the failure(that is certain
variable is having a –ve value though it should
be +ve, etc) are noted.
After it, the cause of error is found and it is
corrected.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 26/32
Code reviews
• Code review is undertaken after the modulesuccessfully compiles.
• Reviews directly detect errors while testing is
done stepwise. Failure finding is the result of testing. hence it is effective.
• There are two types of reviews are carried out
on the code of the module.1)Code walkthrough
2)Code inspection
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 27/32
• Code walkthrough:
The main aim of this is to discover the
algorithmic and logical errors in the code.
• Code inspection:
The main aim of this is to check for the presense
of some common type errors that usually due
to programmer oversights and to check
whether coding standards have been adhered
to.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 28/32
Stress test
• the goals of such tests may be to ensure the softwaredoes not crash in conditions of insufficient computational resources (such as memory or diskspace)
•
Stress testing tries to break the system under test• Stress testing evaluates system performance when it is
stressed for short periods times.
• For eg. Imposing a range of illegal input condition so asto stress the capabilities of the software.
• Input data volume,input data rate,processing time,utiliation of memory etc are tested beyond thedesigned capacity.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 29/32
Load test
• "load testing" is usually defined as the
process of exercising the system under test by
feeding it the largest tasks it can operate with.
• load testing operates at a predefined load
level, usually the highest load that the system
can accept while still functioning properly.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 30/32
Use case based testing
• For each use case typically consists of a
mainline scenario and severalalternate
scenarios.
• The mainline and alternate sequences are
covered to check if any errors show up.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 31/32
automation testing
• .Test automation is the process of writing a computer program todo testing
• This is often the most cost effective method for software products
• There are two general approaches to test automation:
1)Code-driven testing. The public (usually) interfaces to classes,
modules, or libraries are tested with a variety of input arguments tovalidate that the results that are returned are correct.
2)Graphical user interface testing. A testing framework generates userinterface events such as keystrokes and mouse clicks, and observesthe changes that result in the user interface, to validate that theobservable behavior of the program is correct.
7/31/2019 Testing Ch 9
http://slidepdf.com/reader/full/testing-ch-9 32/32
Integration testing
• The primary objective of this testing is to test themodule interfaces, i.e. there are no errors inparameter passing, when one module invokes thefunctionality of another module.
• Four approaches:
1)big-bang integration testing
2)Bottom up
3)Top down
4)Mixed