Documente Academic
Documente Profesional
Documente Cultură
S
Department
SOFTWARE
TESTING
SEE6B
UNIT-I
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
to programs failure
Testing
Starts with known condition,
Debugging
Debugging starts from
and
predictable
2.
outcomes
Testing is a demonstration of
Debugging is a deductiv
programmers failure
Much of testing can be done
vindication
Debugging is impossib
planned,
debugging
S.No
1.
has
designed
and
scheduled
Testing can be done by an
constrained
Debugging must be d
outsider
insider
Page 2
cannot
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
required criteria for delivery to
the end users
f) Personnel:
The staffs should be professional
and experienced in programming
and in the application
g) Standards:
Programming and tests standards
a) Application:
The specifics of the application are
not important
It is a real time system that must
implemented in future
No 2 will be identical, but they
i)
program
the
an
, an OS or a calling program
Human errors lead to create
3 models: a) a model for environment
b) a model of the program
c) a model of the expected bugs
From these models we create a set of tests and
executed
requirement
specifications or not
The main purpose of the test is to
evaluate the systems compliance
with the business requirements
and verify if it has met the
Prepared by, L.Vaishnavi
in
embedded
Page 3
The Environment:
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
1.4. BUG:
performance dependency
3. Medium Bugs- These bugs include DB
errors
A bug occurs when,
A
bug
caused
because
of
not
understanding requirement
Null pointer exceptions
Access violation exceptions
Incorrect format of dates
Bugs due to incorrect syntax
1.5. LEVELS OF TESTING:
in
the
control
structures
of
Page 4
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
Unit
testing
is
performed
by
the
assurance team.
The goal of unit testing is to isolate each
cases.
There
are
two
major
Functional
Testing
Limitations of Unit Testing
path
to
in
evaluate
every
every
software
1.5.2.Integration Testing:
1.5.1.Unit Testing:
Page 5
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
The
application
is
tested
in
an
environment
where
the
Bottom-up integration: This testing begins with unit testing, followed by tests of
System testing enables us to test, verify,
progressively higher-level combinations of units called modules or builds.
and validate
both the
business
requirements as well as the application
architecture.
Top-down integration : In this testing, the highest-level modules are tested first and
1.5.4.Regression Testing:
progressively, lower-level modules are tested thereafter.
Whenever a change in a software
application is made, it is quite possible
1.5.3.System Testing:
following reasons:
following reasons:
tested.
technical specifications.
Page 6
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
Cloudy Directions
Test
coverage
is
increased
without
compromising timelines.
1.5.5.Acceptance Testing:
This test is performed after alpha testing has been
Acceptance tests are not only intended to
point
out
simple
spelling
successfully performed.
mistakes,
as pre-release testing.
production
1.5.6.Alpha Testing:
teams).
Spelling Mistakes
Broken Links
Page 7
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
STRUCTURAL TESTING:
missed accidentally.
In
depth
knowledge
about
the
IMPORTANCE OF BUGS:
Frequency:
Path
Coverage
- This
bug occur?
technique
Correction Cost:
What does it cost to correct the bug
after it is found?
Page 8
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
factors:
5.Serious: It loses track of its transactions
(a) The correction cost
Eg: Accontability is lost
(b) The Cost of discovery
6.Very serious: The bug causes the system to do
(iii)
Installation Cost:
one
bug
and
Long
term
unrecoverable
to be shut down
CONSEQUENCES OF BUGS:
Outputs
redundant. The
are
misleading
bug impacts
the
or
systems
performance
Page 9
PDC-C.S Department
TESTING
a)
SOFTWARE
SEE6B
b) Structural Bugs
c)
Data Bugs
ii)Feature Bugs:
d) Coding Bugs
e)
f)
many features.
Whenever there are specification
bugs.
Corresponding to bugs related to
requirement specification, there
Bugs:
or
extra
feature.
Missing
specification.
implemented,
the
may be deep.
In order to
implications
address
wrong
of many projects.
Ambiguous,
unclear
incomplete
requirements
or
are
Page 10
also,
addressing
wrong
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
b)Structural Bugs:
functionality
is
an
in
outcome
of
In
structured
composition
of
each
of
structural
elements
but interdependent.
Though many a times feature
unambiguous,
implementable,
statements,
the
like
programming
compound
structure.
Also, while structuring, one shall ensure
no redundancy in logic, computation,
representation and declaration.
iv)Functional Bugs:
processing, use
of
Go-TOs
without
Example
related issues
Conditionals
ii)Logic Bugs:
Page 11
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
Example
Switch Case with No Default, Empty Conditional
appropriate
types,
the
values.
In addition, data representation in the
form of data bases and normalization also
plays a very crucial role.
i)Dynamic Vs. Static Data
Dynamic data are
Examples:
outside
proper
iii)Processing Bugs:
Value
and
created
during
the
domain,
Buffer
Exceptions,
memory.
At the end of the transaction, dynamic
Overflow/Underflow,
Arithmetic
Page 12
Control,
and
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
dereferencing
program.
While doing so there can be data bugs that may
the tax rate became effective; in a retail shop, item-wise rate. Control
The internal structure of the code consists of process an
data contains business rules telling the application whatto While
do or how
to
performing
testing, one need to specify execution
behave.
based on program logic, coding standards, programm
Page 13
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
External Interfaces:
some bugs.
In addition, there can be missing device
unavailability
of
serves;
Internal Interfaces:
hardware devices; failure to access the device and so on. Synchronization bugs are of three types: Deadlocks, Ra
Live lock.
Operating System:
Deadlock
Prepared by, L.Vaishnavi
Page 14
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
functionality;
This is an error which results when two threads try to access the same
resource failure to meet required performance; fa
and the result depends on the order of the execution of the threads. volumes of information; failure to handle peak volu
inappropriate documentation; system that is not
Live Lock
server.
efficiency.
input including new functionality and that bug conditions
are properly
Some of the practices like collaborative approach invo
handled.
development
Test methods used in integration testing and functional testing at
integration team
level to strategise testing; review of test
include domain testing, syntax testing, data flow testing.
Prepared by, L.Vaishnavi
Page 15
PDC-C.S Department
TESTING
SOFTWARE
SEE6B
g) Testing
and Design
Test Quality Assurance: Model based Test Maturity Models
(TMM)
is in Style
Bad design and bad code lead to bugs.
practice which is of use in test quality assurance.
Bugs that have origin in design are hard to find and add
Thus,
order to carry out effective testing, good de
Matured test related processes, building skills and competency
in intesters,
rework effort.
In brief, it is always good recommend redesigning rath
Test Design Automation: Slowly but steadily more and more tools are getting
testing on bad design and code.
into test design automation. These tools are of use in automating test design at
code level and also, at system level.
Page 16