Debugging Case-Study: Debugging Process: Steps Involved in Debugging Are
Debugging Case-Study: Debugging Process: Steps Involved in Debugging Are
It is the process of fixing a bug in the software. It can be defined as the identifying, analysing
and removing errors. This activity begins after the software fails to execute properly and
concludes by solving the problem and successfully testing the software. It is considered to be
an extremely complex and tedious task because errors need to be resolved at all stages of
debugging. In other words, it refers to identifying, analysing and removing errors. This
activity begins after the software fails to execute properly and concludes by solving the
problem and successfully testing the software. It is considered to be an extremely complex
and tedious task because errors need to be resolved at all stages of debugging.
Debugging Process: Steps involved in debugging are:
Problem identification and report preparation.
Assigning the report to software engineer to the defect to verify that it is genuine.
Defect Analysis using modelling, documentations, finding and testing candidate
flaws, etc.
Defect Resolution by making required changes to the system.
Validation of corrections.
Debugging Strategies:
Study the system for the larger duration in order to understand the system. It helps
debugger to construct different representations of systems to be debugging depends on
the need.
Backwards analysis of the problem which involves tracing the program backward
from the location of failure message in order to identify the region of faulty code.
Forward analysis of the program involves tracing the program forwards using
breakpoints or print statements at different points in the program and studying the
results.
Debugging Tools: Debugging tool is a computer program that is used to test and debug other
programs. A lot of public domain software like gdb and dbx are available for debugging.
They offer console-based command line interfaces. Examples of automated debugging tools
include code-based tracers, profilers, interpreters, etc. Some of the widely used debuggers are
Radare2, WinDbg, Valgrind.
Understand the design and algorithm – If you are working on a module and you do
not understand its design or its algorithms, then debugging will be very difficult. If
you don't understand the design then you can't test the module because you do not
know what it is supposed to do.
Check correctness – There are several methods for checking correctness of an
implementation prior to execution.
Correctness proofs – One useful code check is to examine code using the logical
methods of correctness proofs. For example, if you know preconditions, invariants,
terminating conditions, and postconditions for a loop then there are some easy checks
that you can make.
Code tracing – Often, errors can be detected by tracing through the execution of
various calls to module services, starting with a variety of initial conditions for the
module. For poorly understood psychological reasons, tracing works best if you are
describing your tracing to someone else. In order to be effective, tracing of a
procedure or function should be done assuming that calls to other procedures and
functions work correctly, even if they are recursive calls.
Peer reviews – A peer review involves having a peer examine your code for errors.
To be effective, the peer should either already be familiar with the algorithm, or
should be given the algorithm and code in advance. When the reviewer meets with the
code writer, the code writer should present the code with explanations of how it
correctly implements the algorithm. If the reviewer doesn't understand or disagrees
with part of the implementation, they discuss that part until both are in agreement
about whether or not it is an error.
Anticipate errors – Unfortunately, humans make errors with correctness arguments
and sometimes miss cases in code tracing, and peers don't always catch errors either.
So, a programmer should be prepared for some errors remaining in the code after the
steps listed above. Hopefully, there won't be too many.
Control Flow X
Testing
Branch Coverage X
Testing
Statement X
Coverage Testing
Decision X
Coverage Testing
Multiple X
Condition
Coverage Testing
Path Flow X
Testing
Finite State X
Testing
Regression X X
Testing
Boundary Value X
Testing
Equivalence X
Class Testing
Decision Table X
Testing
Cause Effect X
Testing
State Transition X
Testing
Syntax Testing X
Functional X
Testing
Non-Functional X
Testing
Unit Testing X X
Integration X X
Testing
System Testing X X
Performance X X
Testing
Usability Testing X
Compatibility X X
Testing
Smoke Testing X X
Sanity Testing X X
Acceptance X X
Testing
Alpha Testing X X
Beta Testing X
Mutation Testing X
Security Testing X X
Load Testing X X
Stress Testing X X
Volume Testing X X