Testing and Debugging

1
 Debugging
● Once errors are identified:
– It is necessary to identify the
precise location of the errors and to
fix them.
● Each debugging approach has its
own advantages and disadvantages:
– Each is useful in appropriate
circumstances.
2
Brute-Force method
● This is the most common method of
debugging:
– Least efficient method.
– Program is loaded with print statements
– Print the intermediate values
– Hope that some of printed values will
help identify the error.

3
 Symbolic Debugger
● Brute force approach becomes more
systematic:
– With the use of a symbolic debugger,
– Symbolic debuggers get their name for
historical reasons
– Early debuggers let you only see
values from a program dump:
● Determine which variable it corresponds to.

4
 Backtracking
● This is a fairly common
approach.
● Beginning at the statement where
an error symptom has been
observed:
– Source code is traced
backwards until the error is
discovered.
5
Example
int function(){
int i,j,s;
i=1;
while(i<=10){
s=s+i;
i++;
j=j++;}
printf(“%d”,s);
}

6
 Backtracking
● Unfortunately, as the number of
source lines to be traced back
increases,
– the number of potential backward
paths increases
– becomes unmanageably large for
complex programs.

7
 Program Slicing
● This technique is similar to back
tracking.
● However, the search space is reduced
by defining slices.
● A slice is defined for a particular
variable at a particular statement:
– set of source lines preceding this statement
which can influence the value of the
variable.

8
 Example
int main(){
int i,s;
i=1; s=1;
while(i<=10){
s=s+i;
i++;}
printf(“%d”,s);
printf(“%d”,i);
}

9
Debugging Guidelines
● Be aware of the possibility:
– an error correction may introduce
new errors.
● After every round of error-
fixing:
– regression testing must be
carried out.

10
Program Analysis Tools
● An automated tool:
– takes program source code as input
– produces reports regarding several
important characteristics of the
program,
– such as size, complexity, adequacy of
commenting, adherence to programming
standards, etc.

11
Program Analysis Tools
● Some program analysis tools:
– Produce reports regarding the
adequacy of the test cases.
● There are essentially two categories
of program analysis tools:
– Static analysis tools
– Dynamic analysis tools

12
 Static Analysis Tools
● Whether coding standards have been
adhered to?
– Commenting is adequate?
● Programming errors such as:
– uninitialized variables
– mismatch between actual and formal
parameters.
– Variables declared but never used, etc.
13
Dynamic Analysis Tools
● Dynamic program analysis
tools require the program to
be executed:
– its behavior recorded.
– Producereports such as
adequacy of test cases.

14
 Testing
● The aim of testing is to identify all defects
in a software product.
● In practice, even after thorough testing, one
cannot guarantee that the software is error-
free.
● Testing does however expose many errors:
– Testing provides a practical way of reducing
defects in a system.
– Increases the users' confidence in a
developed system.
15
 Testing
● Software products are tested
at three levels:
– Unit testing
– Integration testing
– System testing

16
 Unit testing
● During unit testing, modules
are tested in isolation:
– If all modules were to be tested
together:
● it may not be easy to determine
which module has the error.

17
 Unit testing
● Unit testing reduces
debugging effort several
folds.
– Programmers carry out unit
testing immediately after they
complete the coding of a
module.

18
 Integration testing
● After different modules of a
system have been coded and
unit tested:
– modules are integrated in steps
according to an integration plan
– partially integrated system is
tested at each integration step.

19
 Integration Testing
● Develop the integration plan by
examining the structure chart :
– big bang approach
– top-down approach
– bottom-up approach
– mixed approach

20
Example Structured Design
root
Valid-numbers rms
rms
Valid-numbers

Get-good-data Compute-solution Display-solution

Validate-data
Get-data

21
Big Bang Integration Testing
● Big bang approach is the
simplest integration testing
approach:
– all the modules are simply put
together and tested.
– this technique is used only for
very small systems.

22
 Big Bang Integration Testing
● Main problems with this approach:
– If an error is found:
● It is very difficult to localize the error
● The error may potentially belong to any
of the modules being integrated.
– Debugging errors found during big
bang integration testing are very
expensive to fix.
23
Bottom-up Integration
Testing
● Integrate and test the bottom level
modules first.
● A disadvantage of bottom-up
testing:
– when the system is made up of a large
number of small subsystems.
– This extreme case corresponds to the
big bang approach.

24
 Top-down integration
testing
● Top-down integration testing starts with
the main routine:
– and one or two subordinate routines in the
system.

● After the top-level 'skeleton’ has been

25
 Mixed Integration
Testing
● Mixed (or sandwiched)
integration testing:
– usesboth top-down and
bottom-up testing approaches.
– Most common approach

26
 System Testing
● System testing involves:
– validating a fully developed system
against its requirements.
● There are three main kinds of
system testing:
– Alpha Testing

– Beta Testing
– Acceptance Testing 27
 Alpha Testing
● System testing is carried out
by the test team within the
developing organization.

28
 Beta Testing
● System testing performed by
a select group of friendly
customers.

29
 Acceptance Testing
● System testing performed by
the customer himself:
– todetermine whether the
system should be accepted or
rejected.

30
 Stress Testing
● Stress testing (aka endurance testing):
– impose abnormal input to stress the
capabilities of the software.
– Input data volume, input data rate,
processing time, utilization of memory,
etc. are tested beyond the designed
capacity.

31
 How Many Errors are
Still Remaining?
● Seed the code with some known
errors:
– artificial errors are introduced
into the program.
– Check how many of the seeded
errors are detected during
testing.

32
 Error Seeding
● Let:
– N be the total number of errors in
the system
– n of these errors be found by testing.
– S be the total number of seeded
errors,
– s of the seeded errors be found
during testing.

33
 Error Seeding
● n/N = s/S
● N = S * n/s
● remaining defects:
N - n

34
 Example
● 100 errors were introduced.
● 90 of these errors were found
during testing
● 50 other errors were also
found.
● Remaining errors=
50 (100-90)/90 = 6
35
 Error Seeding
● The kind of seeded errors should
match closely with existing errors:
– However, it is difficult to predict the
types of errors that exist.
● Categories of remaining errors:
– can be estimated by analyzing
historical data from similar projects.

36
Thanks

37