Page 282 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes By contrast, software can fail in many bizarre ways. Detecting all of the different failure modes
for software is generally infeasible.

Unlike most physical systems, most of the defects in software are design errors, not manufacturing
defects. Software does not suffer from corrosion, wear-and generally it will not change until
upgrades, or until obsolescence. So once the software is shipped, the design defects will be
buried in and remain latent until activation.

Software bugs will almost always exist in any software module with moderate size: not because
programmers are careless or irresponsible, but because the complexity of software is generally
intractable and humans have only limited ability to manage complexity. It is also true that for
any complex systems, design defects can never be completely ruled out are, is equally difficult,
for the same reason of complexity. Because software and any digital systems are not continuous,
testing boundary values are not sufficient to guarantee correctness. All the possible values
need to be tested and verified, but complete testing is infeasible. Exhaustively testing a simple
program to add only two integer inputs of 32-bits (yielding 2 distinct test cases) would take
64
hundreds of years, even if tests were performed at a rate of thousands per second. Obviously,
for a realistic software module, the complexity can be far beyond the example mentioned here.
If inputs from the real world are involved, the problem will get worse, because timing and
random environmental effects and human interactions are all possible input parameters under
consideration.
A further complication has to do with the dynamic nature of programs. If a failure occurs during
preliminary testing and the code is changed, the software may now work for a test case that it
did not work for previously. But its behaviour on pre-error test cases that it passed before can
no longer be guaranteed. To account for this possibility, testing should be restarted. The expense
of doing this is often prohibitive. Software testing can also provide an objective, independent
view of the software to allow the business to appreciate and understand the risks of software
implementation. Test techniques include, but are not limited to, the process of executing a
program or application with the intent of finding software bug.

14.1 Levels of Testing

Following are the three level of testing.

• Unit testing
• Integration testing
• System testing

14.1.1 Unit Testing
The tests that occur as part of element tests are illustrated schematically. The module boundary
is tested to ensure that information properly flows into and out of the program unit under
test. The local data structure is examined to ensure that data stored provisionally maintains its
integrity during all steps in an algorithm’s execution. Boundary conditions are tested to ensure
that the module operates properly at boundaries established to limit or restrict processing. All
independent paths (basis paths) through the control structure are exercised to ensure that all
statements in a module have been executed at least once. And finally, all error handling paths
are tested.

In ad local data structures should be exercised and the local impact on global data be ascertained
(if possible) during unit testing. Discriminatory testing of execution paths is an essential task
during the unit test cases should be designed to uncover errors due to erroneous computations,
comparisons, or improper control flow.

276 LOVELY PROFESSIONAL UNIVERSITY