-Manan Kantawala

-Roll. No 122
Specify product requirements in a quantifiable
manner before testing starts.

Specify testing objectives explicitly.

Identify the user classes of the software and
develop a profile for each.

Develop a test plan that emphasizes rapid cycle
testing.

Build robust software that is designed to test itself
(e.g. use anti-bugging).

Use effective formal reviews as a filter prior to
testing.

Conduct formal technical reviews to assess the
test strategy and test cases.

Develop a continuous improvement approach for
the testing process.

It focuses on verification effort on smallest unit of
software design (components or modules).
The tests that occur as a part of unit testing
include

The module interface is tested to ensure that
information properly flows into and out of the
program unit under test.

Local data structures are examined to ensure that
data stored temporarily maintains its integrity
during all steps in an algorithms execution.

All independent paths through the control structure are
exercised to ensure that all statements in a module have
been executed at least once.

Boundary conditions are tested to ensure that the module
operates properly at boundaries.

All error handling paths are tested.

Selective testing of execution paths is an essential task
during the unit test.

Test cases should be designed to uncover errors due to
erroneous computations, incorrect comparisons or improper
control flow.

Test cases should uncovers errors like:
Comparison of different data types
Incorrect logical operators or precedence
Incorrect comparison of variables

Boundary testing is one of the most important unit
testing tasks.

Because a component is not a stand-
alone program, driver or stub s/w must
be developed for each unit test.

Driver is like a main program that
accepts test case data, passes such data
to the component and prints relevant
results.
Stubs serve to replace modules that are
subordinate to the component to be tested.

Drivers and stubs represent overhead.

Unit testing is simplified when a component
with high cohesion is designed.


It is always a good idea to develop and test
software in "pieces". But, it may seem
impossible because it is hard to imagine how
you can test one "piece" if the other "pieces"
that it uses have not yet been developed
(and vice versa).

To solve this kind of difficult problems we
use stubs and drivers.

Driver is a the piece of code that passes test
cases to another piece of code. Test Harness
or a test driver is supporting code and data
used to provide an environment for testing
part of a system in isolation.
It can be called as a software module which
is used to invoke a module under test and
provide test inputs, control and, monitor
execution, and report test results or most
simplistically a line of code that calls a
method and passes that method a value.
Test stubs are programs which simulate the
behaviours of software components (or modules)
that are the dependent modules of the module
being tested.
Four common types of Stubs are:

1. show a trace message
2. show parameter value(s)
3. Return a value from a table
4. Return table value selected by parameter
Stub is a program that is utilized as an alternate
for the modules body of the software which is or
would be defined in a different place or an object
or dummy component utilized to imitate the
conduct of an actual component until that
component is developed.

At last, the artificial process would be
accomplished with the correct logic of a program.
All the same, developing the stub permits the
developer for calling a method in source code that
is developed, yet the method do not have the
desirable performance.