Term Paper

Of

Testing for Real Time

(CSE314)

SUBMITTED TO:
Miss Rajni Bhalla

SUBMITTED BY:
Sunil Kakkar
RC2702B42
B.Tech-M-Tech (IT)
Homework Title / No. : Testing for Real Time

Course Instructor: Miss.Rajni Bhalla Course Tutor (if applicable):

Date of Allotment: Date of submission 10/05/10

Student’s Roll No. 3070070049,42 Section No. : C2702

Declaration:

I declare that this assignment is my individual work. I have not copied from any other
student’s work or from any other source except where due acknowledgment is made
explicitly in the text, nor has any part been written for me by another person.

Student’s Signature: Sunil

Evaluator’s comments:
_____________________________________________________________________

Marks obtained: ___________ out of ______________________

Content of Homework should start from this page only:

 ACKNOWLEDGEMENT

When we do anything, we always want to thank all those people who have left an impression
on our lives and inspired us to greatness. Before we got things I would like to add a few
heartfelt words for the people who were part of this term paper in numerous ways. Our
sincere gratitude to Miss Rajni Bhalla for his valuable guidance, encouragement, useful
suggestion, critical evaluation and unending support which helped us accomplishes the term
paper. Although I have expressed our gratitude and heartfelt thanks to friends, who helped me
in reaching at this stage, but there might be a few, who’d been left out, I would like to thank
all of them for being a constant motivation and inspiration to me.

(SUNIL KAKKAR)
 Real time testing
Abstract
During the development of a
real-time application, a testing
step is necessary to check the
conformity of the
implementation in accordance
with its speciation. The test
sequences, also named
temporised tests, have got
temporal constraints because not
only the events, but also the
dates of these events need to be
verify. In this article, we firstly
present a method which permits
to transcribe temporised test in
TTCN for a local architecture.
Then, as it's generally more
convenient to use a distributed
architecture, we introduce here a
new architecture which permits
to take into account the round
trip delay of a message in the
network and also an expansion
of our method for this case. This
architecture is based on a
reliable communication between
a "spy" and the tester.
Introduction
Software testing is an
investigation conducted to
provide stakeholders with
information about the quality of
the product or service under test.
Software Testing also provides
an objective, independent view
of the software to allow the
business to appreciate and
understand the risks at
implementation of the software.
Test techniques include, but are
not limited to, the process of
executing a program or
application with the intent of
finding software bugs.
Software Testing can also be
stated as the process of
validating and verifying that a
software
program/application/product:
1. meets the business and
technical requirements
that guided its design and
development;
2. works as expected; and
3. can be implemented with
the same characteristics.
Software Testing, depending on
the testing method employed,
can be implemented at any time
in the development process.
However, most of the test effort
occurs after the requirements
have been defined and the
coding process has been
completed. As such, the
methodology of the test is
governed by the Software
Development methodology
adopted.
Different software development
models will focus the test effort
at different points in the
development process. Newer
development models, such as
Agile, often employ test driven
development and place an Why are we learning Real
increased portion of the testing
in the hands of the developer,
time testing?
before it reaches a formal team
•A Real Time System must run
of testers. In a more traditional
model, most of the test continuously until it has been
execution occurs after the powered off
requirements have been defined
and the coding process has been •Failure to run properly can
completed.
mean great economic loss and/or

Real time testing loss of human life

Evaluation of a system (or its A LARGE PART OF REAL

components) at its normal TIME SOFTWARE
operating frequency,
speed, or timing. DEVELOPMENT

MUST FOCUS ON AVOIDING

What is Software testing? FAILURE

How to minimizing failure

Software testing is an
in real time systems:
investigation conducted to
provide stakeholders with – Software Test (various levels)
information about the quality of
– System Test
the product or service under test.
Software Testing also provides Build test and recovery software
an objective, independent view and/or hardware into the design
of the software to allow the
– Exception handling (limit
business to appreciate and
checking, etc.) to recover from
understand the risks at
bad data inputs
implementation of the software.
Software Testing can also be – Redundant hardware solutions
stated as the process of (e.g. 5 processors on Space
validating and verifying that a Shuttle)
software
program/application/product.
– Fault Tolerant software and establishes the start of the
hardware warranty period.
• Testing can take up to 50%
Functional vs non-
of a project’s budget and
functional testing
schedule
Functional testing refers to tests
that verify a specific action or
function of the code. These are
usually found in the code
requirements documentation,
although some development
methodologies work from use
cases or user stories. Functional
tests tend to answer the question
of "can the user do this" or "does
this particular feature work".

Non-functional testing refers to

aspects of the software that may
not be related to a specific
function or user action, such as
scalability or security. Non-
functional testing tends to
answer such questions as "how
many people can log in at once",
or "how easy is it to hack this
software".
Real Time System Testing
Diagram
• Testing is an important part
of the software life cycle- A
good testing program is a tool
for both the agency and the
integrator/supplier; it typically
identifies the end of the
“development” phase of the
project, establishes the criteria
for project acceptance, and
Defects and failures
Not all software defects are
caused by coding errors. One
common source of expensive
defects is caused by requirement
gaps, e.g., unrecognized
requirements, that result in
errors of omission by the
program designer. A common
source of requirements gaps is
non-functional requirements
such as testability, scalability,
maintainability, usability,
performance, and security.
Software faults occur through
the following processes. A
programmer makes an error
(mistake), which results in a
defect (fault, bug) in the
software source code. If this
defect is executed, in certain
situations the system will
produce wrong results, causing a
failure.Not all defects will
necessarily result in failures. For
example, defects in dead code
will never result in failures. A
defect can turn into a failure
when the environment is
changed. Examples of these
changes in environment include
the software being run on a new
hardware platform, alterations in
source data or interacting with
different software. A single
defect may result in a wide
range of failure symptoms.
Compatibility
A common cause of software
failure (real or perceived) is a
lack of compatibility with other
application software, operating
systems (or operating system
versions, old or new), or target
environments that differ greatly
from the original (such as a
terminal or GUI application
intended to be run on the
desktop now being required to
become a Web application,
which must render in a Web
browser). For example, in the
case of a lack of backward
compatibility, this can occur
because the programmers
develop and test software only
on the latest version of the target
environment, which not all users
may be running. This results in
the unintended consequence that
the latest work may not function
on earlier versions of the target
environment, or on older
hardware that earlier versions of
the target environment was
capable of using. Sometimes
such issues can be fixed by
proactively abstracting operating
system functionality into a
separate program module or
library.
Input combinations and
preconditions
A very fundamental problem
with software testing is that
testing under all combinations of
inputs and preconditions (initial
state) is not feasible, even with a
simple product. This means that
the number of defects in a
software product can be very
large and defects that occur
infrequently are difficult to find
in testing. More significantly,
non-functional dimensions of
quality (how it is supposed to be
versus what it is supposed to do)
—usability, scalability,
performance, compatibility,
reliability—can be highly
subjective; something that
constitutes sufficient value to
one person may be intolerable to
another.
Static vs. dynamic testing
There are many approaches to
software testing. Reviews,
walkthroughs, or inspections are
considered as static testing,
whereas actually executing
programmed code with a given
set of test cases is referred to as
dynamic testing. Static testing
can be (and unfortunately in
practice often is) omitted.
Dynamic testing takes place
when the program itself is used
for the first time (which is
generally considered the
beginning of the testing stage).
Dynamic testing may begin
before the program is 100%
complete in order to test
particular sections of code
(modules or discrete functions).
Typical techniques for this are
either using stubs/drivers or
execution from a debugger
environment. For example,
Spreadsheet programs are, by
their very nature, tested to a
large extent interactively ("on
the fly"), with results displayed
immediately after each
calculation or text manipulation.
Testing Methods
Black Box Testing
Black-box testing uses external
descriptions of the software,
including specifications,
requirements, and design to
derive test cases. These tests can
be functional or non-functional,
though usually functional. The
test designer selects valid and
invalid inputs and determines
the correct output. There is no
knowledge of the test object's
internal structure.
This method of test design is
applicable to all levels of
software testing: unit,
integration, functional testing,
system and acceptance. The
higher the level, and hence the
bigger and more complex the
box, the more one is forced to
use black box testing to
simplify. While this method can
uncover unimplemented parts of
the specification, one cannot be
sure that all existent paths are
tested.
White Box Testing
White box testing (a.k.a. clear
box testing, glass box testing,
transparent box testing, or
structural testing) uses an
internal perspective of the
system to design test cases based
on internal structure. It requires
programming skills to identify
all paths through the software.
The tester chooses test case
inputs to exercise paths through
the code and determines the
appropriate outputs. In electrical
hardware testing, every node in
a circuit may be probed and
measured; an example is in-
circuit testing (ICT).
Since the tests are based on the
actual implementation, if the
implementation changes, the
tests probably will need to
change, too. For example ICT
needs updates if component
values change, and needs
modified/new fixture if the
circuit changes. This adds
financial resistance to the
change process, thus buggy
products may stay buggy.
Automated optical inspection
(AOI) offers similar component
level correctness checking
without the cost of ICT fixtures,
however changes still require
test updates.
While white box testing is
applicable at the unit, integration
and system levels of the
software testing process, it is
typically applied to the unit.
While it normally tests paths
within a unit, it can also test
paths between units during
integration, and between
subsystems during a system
level test. Though this method of
test design can uncover an
overwhelming number of test
cases, it might not detect
unimplemented parts of the
specification or missing
requirements, but one can be
sure that all paths through the
test object are executed.
Typical white box test design
techniques include:
• Control flow testing
• Data flow testing
• Branch testing
• Path testing
Levels of Real Time
System Testing
•Unit Testing-It is a software
verification and validation
method in which a programmer
tests if individual units of source
code are fit for use. A unit is the
smallest testable part of an
application. In procedural
programming a unit may be an
individual function or procedure.
•Software Integration Testing-
It is the phase in software testing
in which individual software
modules are combined and
tested as a group. It occurs after
unit testing and before system
testing. Integration testing takes
as its input modules that have
been unit tested, groups them in
larger aggregates, applies tests
defined in an integration test
plan to those aggregates, and
delivers as its output the
integrated system ready for
system testing.
•Software Validation and
Verification Testing-It is the
process of checking that a
software system meets
specifications and that it fulfils
its intended purpose. It is
normally part of the software
testing process of a project.
Software / Hardware
Integration Testing- Identify
the sequence of integrating
software build(s) with the
hardware modules. Identify the
product features/functions being
built up at each step.
System Testing-System testing
of software or hardware is
testing conducted on a complete,
integrated system to evaluate the
system's compliance with its
specified requirements.
Why Test? - Some Real
World Examples
• An F-16 pilot was sitting
on the runway doing the
pre-flight and wondering
if the computer would let
him raise the landing
gear while on the
ground….it did!
 • When initially Test is an important part of
developing the the real time software life cycle
sidewinder missile
A large portion of our effort
mounting, there were a
must focus on avoiding failure
few problems.
• Testing:
The software would release the
latch and fire the missile. • Uncovers errors
Initially, the latch was closed too
• Fixes errors
quickly and the missile could
never leave the wing. Imagine • Measures requirements
the pilot’s dismay when there conformance
was suddenly extra thrust on one
• Provides an indication
of the wings!!
of quality
• The F-16 has a
• Testing can be black box
sophisticated s/w system
(inputs/outputs) or white
that performs load
box (software paths)
balancing to optimize
oriented
flight performance. This
includes dropping empty • Testing is performed at
fuel tanks in such a way several levels (unit,
as to balance the plane. software integration,
A minor prerequisite to sw/hw integration,
dropping the tank was system)
overlooked in the
software - it is usually a
References
good idea to be upright
when releasing the tanks.
www.google.com
Imagine flying upside www.wikipedia.com
down and having empty www.ibm.com
www.wikianswers.co
fuel tanks come flying
m
off! www.uncyclopedia.c
om
Summary