Module I

TESTING
Testing is the process of evaluating a system or its component(s) with the intent to find
that whether it satisfies the specified requirements or not. This activity results in the actual,
expected and difference between their results. In simple words testing is executing a system in
order to identify any gaps, errors or missing requirements in contrary to the actual desire or
requirements. Testing can be defined as “A process of analyzing a software item to detect
the differences between existing and required conditions (that is defects / errors/bugs) and
to evaluate the features of the software item”.

Difference between Testing and Debugging

Testing : It involves the identification of bug/error/defect in the software without correcting it.
Normally professionals with a Quality Assurance background are involved in the identification of
bugs. Testing is performed in the testing phase.

Debugging : It involves identifying, isolating and fixing the problems/bug. Developers who code
the software conduct debugging upon encountering an error in the code. Debugging is the part of
White box or Unit Testing. Debugging can be performed in the development phase while
conducting Unit Testing or in phases while fixing the reported bugs.

• Testing starts with known conditions ,uses predefined procedures, and has predictable
outcomes. Debugging starts from possibly unknown initial conditions, and the end cannot
be predicted.
• Testing can be planned, designed, and scheduled. The procedure for, and duration of,
debugging cannot be so constrained.
• Testing is a demonstration of error or apparent correctness. Debugging is a deductive
process.
• Testing proves programmer’s failure. Debugging is the programmer’s vindication.
• Much of testing can be done without design knowledge. Debugging is impossible without
detailed design knowledge.
• Testing is often done by an outsider. Debugging must be done by an insider (programmer).

DIFFERENCE BETWEEN VERIFICATION & VALIDATION

Verification Validation
Are you building it right? Are you building the right thing?

Ensure that the software system meets all Ensure that functionalities meet the
the functionality. intended behavior.

Verification takes place first and includes Validation occurs after verification and
the checking for documentation, code etc. mainly involves the checking of the overall
product.

Don Bosco College, Kottiyam Page 1

 Done by developers. Done by Testers.

Have static activities as it includes the Have dynamic activities as it includes

reviews, walkthroughs, and inspections to executing the software against the
verify that software is correct or not. requirements.

It is an objective process and no subjective It is a subjective process and involves

decision should be needed to verify the subjective decisions on how well the
Software. Software works.

Functional Technique and Structural Technique

Different techniques reveal different quality aspects of a software system, and there are two major
categories of testing techniques, functional and structural.

Functional Testing: The software program or system under test is viewed as a “black box”.
The selection of test cases for functional testing is based on the requirement or design
specification of the software entity under test. It is subjected to inputs, and its outputs are verified
for conformance to specified behavior. It is concerned only with functionality and features ,and
not program’s implementation details. Functional testing emphasizes on the external behavior
of the software entity.

Structural Testing: The software entity is viewed as a “white box”. The selection of test cases
is based on the implementation of the software entity, such as programming style, control
methods, source language, database design, coding details, program branches or paths. The
expected results are evaluated on a set of coverage criteria. Structural testing emphasizes on
the internal structure of the software entity.

TESTING METHODS

There are different methods in software testing.

Black Box Testing

The technique of testing without having any knowledge of the interior workings of the application
is Black Box testing. The tester is oblivious to the system architecture and does not have access
to the source code. Typically, when performing a black box test, a tester will interact with the
system’s user interface by providing inputs and examining outputs without knowing how and
where the inputs are worked upon.

Advantages:

• Well suited and efficient for large code segments.

• Code Access not required.

Don Bosco College, Kottiyam Page 2

 • Clearly separates user’s perspective from the developer’s perspective through visibly
defined roles.
• Large numbers of moderately skilled testers can test the application with no knowledge of
implementation, programming language or operating systems.
Disadvantages:
• Limited Coverage since only a selected number of test scenarios are actually performed.
• Inefficient testing, due to the fact that the tester only has limited knowledge about an
application.
• Blind Coverage, since the tester cannot target specific code segments or error prone
areas.
• The test cases are difficult to design.

White Box Testing

White box testing is the detailed investigation of internal logic and structure of the code. White
box testing is also called glass testing or open box testing. In order to perform white box testing
on an application, the tester needs to possess knowledge of the internal working of the code.
The tester needs to have a look inside the source code and find out which unit of the code is
behaving inappropriately.

Advantages:
• As the tester has knowledge of the source code, it becomes very easy to find out which
type of data can help in testing the application effectively.
• It helps in optimizing the code.
• Extra lines of code can be removed which can bring in hidden defects.
• Due to the tester's knowledge about the code, maximum coverage is attained during test
scenario writing.
Disadvantages:
• Due to the fact that a skilled tester is needed to perform white box testing, the costs are
increased.
• Sometimes it is impossible to look into every nook and corner to find out hidden errors that
may create problems as many paths will go untested.
• It is difficult to maintain white box testing as the use of specialized tools like code analyzers
and debugging tools are required.

Grey Box Testing

Grey Box testing is a technique to test the application with limited knowledge of the internal
workings of an application. Unlike black box testing, where the tester only tests the application’s
user interface, in grey box testing, the tester has access to design documents and the database.
Having this knowledge, the tester is able to better prepare test data and test scenarios when
making the test plan.

Don Bosco College, Kottiyam Page 3

Advantages:
• Offers combined benefits of black box and white box testing wherever possible.
• Grey box testers don’t rely on the source code; instead they rely on interface definition
and functional specifications.
• Based on the limited information available, a grey box tester can design excellent test
scenarios especially around communication protocols and data type handling.
• The test is done from the point of view of the user and not the designer.
Disadvantages:
• Since the access to source code is not available, the ability to go over the code and test
coverage is limited.
• The tests can be redundant if the software designer has already run a test case.
• Testing every possible input stream is unrealistic because it would take an unreasonable
amount of time; therefore, many program paths will go untested.

Black Box Testing Grey Box Testing White Box Testing

The Internal Workings of an Somewhat knowledge of the Tester has full knowledge of
application are not internal workings are the
required to known Internal workings of
be known the application

Also known as closed box Another term for grey box Also known as clear box
testing, data driven testing testing is translucent testing testing, structural testing or
and functional as the tester has limited code based
testing knowledge of the testing
insides of the application

Performed by end users Performed by end users Normally done by

and also by testers and and also by testers and testers and developers
developers developers

Testing is based on Testing is done on the Internal workings are

external expectations, Internal basis of high level fully known and the
behavior of the database diagrams and tester can design test
application is unknown data flow diagrams data accordingly

This is the least time Partly time consuming The most exhaustive
consuming and and exhaustive and time consuming
exhaustive type of testing

Not suited to algorithm Not suited to algorithm testing Suited for algorithm testing
testing

Don Bosco College, Kottiyam Page 4

 This can only be done by Data domains and Internal Data domains and Internal
trial and error method boundaries can be tested, if boundaries can be better
known tested

LEVELS OF TESTING
There are different levels during the process of testing. Levels of testing include the different
methodologies that can be used while conducting Software Testing. Following are the main levels
of Software Testing:

• Functional Testing.
• Non-functional Testing.
FUNCTIONAL TESTING

This is a type of black box testing that is based on the specifications of the software that is to be
tested. The application is tested by providing input and then the results are examined that need
to conform to the functionality it was intended for.
1. Unit Testing
This type of testing is performed by the developers before the setup is handed over to the testing
team to formally execute the test cases. Unit testing is performed by the respective developers
on the individual units of source code assigned areas. The developers use test data that is
separate from the test data of the quality assurance team .The goal of unit testing is to isolate
each part of the program and show that individual parts are correct in terms of requirements and
functionality.
2. Integration Testing
The testing of combined parts of an application to determine if they function correctly together is
Integration testing. There are two methods of doing Integration Testing Bottom-up Integration
testing and Top Down Integration testing
• Bottom-up integration testing begins with unit testing, followed by tests of progressively
higher-level combinations of units called modules or builds.
• Top-Down integration testing, the highest-level modules are tested first and
progressively lower-level modules are tested after that. In a comprehensive software
development environment, bottom-up testing is usually done first, followed by top-down
testing.
3. System Testing
This is the next level in the testing and tests the system as a whole. Once all thecomponents are
integrated, the application as a whole is tested rigorously to see that it meets Quality Standards.
This type of testing is performed by a specialized testing team.
Why is System Testing so Important
• System Testing is the first step in the Software Development Life Cycle, where the
application is tested as a whole.

Don Bosco College, Kottiyam Page 5

 • The application is tested thoroughly to verify that it meets the functional and technical
specifications.
• The application is tested in an environment which is very close to the production
environment where the application will be deployed.
• System Testing enables us to test, verify and validate both the business requirements as
well as the Applications Architecture.

4. Regression Testing
Whenever a change in a software application is made it is quite possible that other areas within
the application have been affected by this change. To verify that a fixed bug hasn’t resulted in
another functionality or rule violation is Regression testing. The intent of Regression testing is to
ensure that a change, such as a bug fix did not result in another fault being uncovered in the
application.

5. Acceptance Testing
This is the most importance type of testing as it is conducted by the Quality Assurance Team
who will gauge whether the application meets the intended specifications and satisfies the client’s
requirement. The QA team will have a set of pre written scenarios and Test Cases that will be
used to test the application.
By performing acceptance tests on an application the testing team will deduce how the
application will perform in production. There are also legal and contractual requirements for
acceptance of the system.
1. Alpha Testing
This test is the first stage of testing and will be performed amongst the teams (developer and QA
teams). During this phase, the following will be tested in the application.

• Spelling Mistakes
• Broken Links
• Cloudy Directions
• The Application will be tested on machines with the lowest specification to test loading
times and any latency problems.
2. Beta Testing
This test is performed after Alpha testing has been successfully performed. In beta testing a
sample of the intended audience tests the application. Beta testing is also known as pre-
release testing. Beta test versions of software are ideally distributed to a wide audience on
the Web, partly to give the program a "real-world" test and partly to provide a preview of the
next release. In this phase the audience will be testing the
following:
• Users will install, run the application and send their feedback to the project team.
• Typographical errors, confusing application flow, and even crashes.
• Getting the feedback, the project team can fix the problems before releasing the
software to the actual users.
• The more issues you fix that solve real user problems, the higher the quality of your
application will be.

Don Bosco College, Kottiyam Page 6

 •Having a higher-quality application when you release to the general public will increase
customer satisfaction.
NON-FUNCTIONAL TESTING

The testing of the application from its non-functional attributes. Non-functional testing of Software
involves testing the Software from the requirements which are non-functional in nature. But gives
importance in performance, security, user interface etc. Some of the important and commonly
used non-functional testing types are mentioned as follows.

1 Performance Testing
It is mostly used to identify any bottlenecks or performance issues rather than finding the bugs in
software. There are different causes which contribute in lowering the performance of software:
• Network delay.
• Client side processing.
• Database transaction processing.
• Load balancing between servers.
• Data rendering.
Performance testing is considered as one of the important and mandatory testing type in terms of
following aspects:
Speed (i.e. Response Time, data rendering and accessing)
• Capacity
• Stability
• Scalability
It can be either qualitative or quantitative testing activity and can be divided into different sub
types such as
Load testing and Stress testing.
I. Load Testing
A process of testing the behavior of the Software by applying maximum load in terms of Software
accessing and manipulating large input data. It can be done at both normal and peak load
conditions. This type of testing identifies the maximum capacity of Software and its behavior at
peak time.
II. Stress Testing
This testing type includes the testing of Software behavior under abnormal conditions. Taking
away the resources, applying load beyond the actual load limit is Stress testing. The main intent
is to test the Software by applying the load to the system and taking over the resources used by
the Software to identify the breaking point. This testing can be performed by testing different
scenarios such as:
• Shutdown or restart of Network ports randomly.
• Turning the database on or off.
• Running different processes that consume resources such as CPU, Memory, server etc.

2 Usability Testing
Usability testing ensures that a good and user friendly GUI is designed and is easy to use for the
end user. UI testing can be considered as a sub part of Usability testing. UI testing involves the

Don Bosco College, Kottiyam Page 7

testing of Graphical User Interface of the Software. This testing ensures that the GUI should be
according to requirements in terms of color, alignment, size and other properties.

3 Security Testing
Security testing involves the testing of Software in order to identify any flaws ad gaps from security
and vulnerability point of view. Following are the main aspects which Security testing should
ensure:
• Confidentiality
• Integrity
• Authentication
• Availability

4 Portability Testing
Portability testing includes the testing of Software with intend that it should be re-useable and can
be moved from another Software as well. Following are the strategies that can be used for
Portability testing.
• Transferred installed Software from one computer to another.
• Building executable (.exe) to run the Software on different platforms.

TESTING DOCUMENTATION
Documentation for Software testing helps in estimating the testing effort required, test coverage,
requirement tracking/tracing etc.
• Test Plan
• Test Scenario
• Test Case
• Traceability Matrix

1. Test Plan
A test plan outlines the strategy that will be used to test an application, the resources that will be
used, the test environment in which testing will be performed, the limitations of the testing and the
schedule of testing activities. Typically the Quality Assurance Team Lead will be responsible for
writing a Test Plan. A test plan will include the following.
• Introduction to the Test Plan document
• Assumptions when testing the application
• List of test cases included in Testing the application
• List of features to be tested
• What sort of Approach to use when testing the software
• List of Deliverables that need to be tested
• The resources allocated for testing the application
• Any Risks involved during the testing process

Don Bosco College, Kottiyam Page 8

 2 Test Scenarios
Test Scenarios are used to ensure that all process flows are tested from end to end. A particular
area of an application can have as little as one test scenario to a few hundred scenarios
depending on the magnitude and complexity of the application.

3 Test Case
Test cases involve the set of steps, conditions and inputs which can be used while performing the
testing tasks. The main intent of this activity is to ensure whether the Software Passes or Fails in
terms of its functionality and other aspects. There are many types of test cases like: functional,
negative, error, logical test cases, physical test cases, UI test cases etc. The following are the
main components which are always available and included in every test case:

• Test case ID.

• Product Module
• Product version
• Revision history
• Purpose
• Assumptions
• Pre-Conditions.
• Steps.
• Expected Outcome.
• Actual Outcome.
• Post Conditions.

4 Traceability Matrix
Traceability Matrix (also known as Requirement Traceability Matrix -RTM) is a table which is used
to trace the requirements during the Software development life Cycle. It can be used for forward
tracing (i.e. from Requirements to Design or Coding) or backward (i.e. from Coding to
Requirements). There are many user defined templates for
RTM. Each requirement in the RTM document is linked with its associated test case, so that
testing can be done as per the mentioned requirements. Furthermore, Bug ID is also include and
linked with its associated requirements and test case. The main goals for this
• Make sure Software is developed as per the mentioned requirements.
• Helps in finding the root cause of any bug.
• Helps in tracing the developed documents during different phases of SDLC

BUG TAXONAMY

Don Bosco College, Kottiyam Page 9

Bug taxonomies help in providing fast and effective feedback so that they can easily identify
possible reasons for failure of the software. Using bug taxonomy, a large number of potential bugs
can be grouped into few categories. Whenever a new bug is reported, using bug taxonomy, a
tester can easily analyse and put that bug into any of these categories. At the end of testing,
testers can understand the type of categories of bugs that frequently occurred and thereby in
successive rounds of testing he can focus on writing more test cases that would help to detect
such bugs. In addition, test leaders can guide their testers to focus on such frequently occurring
bugs.

Bugs are difficult to categorize. Though there is no universally correct way to categorize bugs, it
is recommended to adapt some taxonomy to categorize bugs. This would help in test strategy.
An extensive bug taxonomy which classifies bugs based on the possible places in various phases
of development cycle. The major categories are- requirements, features and functionalities,
structure, data, implementation and coding, integration, system and software architecture, and
testing. The Bug Taxonomy is given below.

• Requirements, Features, and Functionality Bugs

• Structural Bugs
• Data Bugs
• Coding Bugs
• Interface, Integration, and System Bugs
• Test and Test Design Bugs
• Test and Design Cycle

1. Requirements, Features, and Functionality Bugs

Requirements expressed by client and user are captured by requirements study team and then
they are segregated, documented, reviewed, and approved so as to formalize into a requirements
specification. Each requirement appearing in the specification has many features that need to be
implemented in the project to produce software. Following sections provide some insight into
requirements and specification related bugs, features related bugs.

a. Requirements and Specification related Bugs

The bugs in requirements are a contributing cause to the failure of many projects. Ambiguous,
unclear or incomplete requirements are serious problems but they are not the sole source of
requirements bugs. Even when there are no bugs like ambiguous, unclear or incomplete
requirements, we may expect new type of bugs because of changing features are new change
requests.

b. Feature Bugs

Don Bosco College, Kottiyam Page 10

Each requirement is made up of many features. Whenever there are specification related bugs,
corresponding to that there will be feature related bugs. Corresponding to bugs related to
requirement specification, there will be feature related bugs like wrong feature, missing feature,
or extra feature. Missing feature is relatively easy to identify and also, to address. In case of wrong
feature, one needs to change all earlier documents till that phase where wrong feature is detected
and also, addressing wrong features may include changes in design and code. As such these are
very costly and cause delay in project completion.

Testing techniques

Requirements, Features, and Functionality Bugs can be detected by using functional testing
techniques, namely, transaction flow testing, syntax testing, domain testing, logic testing, and
state testing. Also, formal technical reviews which are part of static testing are capable of finding
bugs in requirements and also, traceability related issues.

2. Structural Bugs

In structured programming the composition of each of structural elements like statements, compound
statements, loops and their nesting play an important role in ensuring better quality structure. Also,
while structuring, one shall ensure no redundancy in logic, computation, representation and
declaration. Also, there shall be no inefficiency. Also all statements shall be represented with proper
naming convention, direct and simple to understand. Also, every declared structural form should be
utilized. However all these expectations are easy to list than to achieve. There are many violations
that would result in structural bugs. Following are the different structural bugs.

a. Control and Sequence Bugs

Control flow specifies a sequence in which instructions (events or paths) are executed in a component
or system. Control flow and sequence are the most common but can be easily found during unit testing.

Control flow bugs include unreachable or dead code, improper nesting of loops, un-tested paths, loop-
back and loop exit criteria, incorrect or missing process steps, duplicated processing, un-necessary
processing, use of Go-TOs without justification and so on.

Example
Unreachable or Dead Code
Unreachable or dead code refers to that part of code which will never be executed. Mistaken
statement terminators, unintentional termination of loop after first execution may result in common
dead code problems.

b. Logic bugs
Logic bugs are related to misunderstanding on behavior of case statements and logic operators
either singly or in combination and also, misunderstanding of the semantics of the order in which
a Boolean expression is evaluated for specific compiler.

Examples of logic bugs include- improper lay-out of cases improper negation of Boolean
expression, improper simplification and combination of cases etc.

Example: Switch Case with No Default

Don Bosco College, Kottiyam Page 11

If there is no default case in a ‘switch’ statement, the behavior can be unpredictable. Such a
practice can result in a bug like NULL dereferences memory leak as well as other types of serious
bugs.

c. Processing Bugs

Processing bugs are easy to find bugs during unit testing and have an effect in the program where
they occur. These bugs include- arithmetic bugs, algebraic bugs, wrong evaluation of
mathematical formula, and inappropriate selection of algorithm, ignoring over-flow, improper use
of logical and relational operators.

Examples: Buffer Overflow/Underflow

When code puts data into buffer without having any kind of checking, we may arrive at Buffer
Overflow error. A simple buffer overflow is capable of putting the security of the system at risk. It
can cause following vulnerabilities like- attacking Stack- Modify the return address to execute
malicious code; Pointer overriding to get data on a specific location; an array index out of bounds;
heap overflows attack.

Arithmetic Exceptions: Arithmetic exceptions sometimes are incomputable resulting in this class
of errors. Some examples are: divide by zero, floating point exceptions etc.

d. Initialization Bugs

Initialization errors are common and both new and also, experienced programmers alike do these
mistakes. These bugs may include no initiation or under initiation or over initialization. Typical
bugs include- no initialization of working space registers or data variables before first use, bug in
the initial value in the loop-control parameter, accepting an initial value without validation check,
initialization with wrong data type or representation.

Un-initialized Memory: If initialization is not proper after declaration, some possible scenarios
and paths may not be executed. Such cases impose problems like un-initialized memory.

Off by one: When loops are under-initialized or over-initialized, or > is written instead of >= etc,
we may get these errors.

e. Data Flow Bugs and Anomalies

Data flow is a representation of the sequence and possible changes of state of data objects,
where the state of an object is any of creation, usage, modification or destruction. Data flow
structure follows that trail of a data item as it is accessed and modified by the code. Using Data
Flow measures one can understand how the data acts as they are transformed by the program.
While data is undergoing such a transformation, a data flow anomaly occurs when there is
something unexpected or unreasonable with data occurs. Bugs like referencing a variable with an
undefined value and variables that are never used, initialization bugs, modifying data and not
using the result, attempting to using the variable without defining it, double initialization are some
example of data flow anomalies and bugs.

Don Bosco College, Kottiyam Page 12

Example: Buffer overflow - Execute malicious code

By means of a buffer overflow condition the computer can be made to execute arbitrary and a
potentially malicious code that is fed to the buggy program as an input data.

3. Data Bugs

Success of any program depends on its code and also, data. So it is important to give due
attention to data as well like the way we give importance to the code. Data may be in any form,
viz., Communication Data (messages), Composite Data, Computation Data, Data Structures,
Operator Input Data, Security Data, Transaction Data, Concurrently Shared Data, Meta-level
Data, Pointer/ Addressing Data. However, data can be either static or dynamic. Data is
represented in code as: data types, constants, variables, and records. Data bugs arise while
selecting appropriate and proper types, the specifications, their formats, the number of such data
objects, and their initial values. In addition, data representation in the form of data bases and
normalization also plays a very crucial role.

Note:

Dynamic Vs. Static Data

Dynamic data are transitory that undergo asynchronous change. These data are created during
the transaction and stored in the shared memory. At the end of the transaction, dynamic data has
no relevance and shared memory is released back to the system. Thus dynamic data has
relatively short time life time that is typically equal to the processing time. The dynamic data so
produced during processing is being used to produce results. If the results are not as per our
expectation, it is hard to locate the cause behind these bugs and as such bugs produced by
dynamic data are hard to find and also, performing root cause analysis is not easy.

Static data is the data that rarely changes. This may be the data that is hard coded in the code
or may appear as a constant or data stored in a database. Data like name of the company, it’s
address etc are examples of static data.

Examples: Dealing with Volatile Objects

When we are dealing with global volatile objects which are going to be shared between several
threads, if necessary extra checking is not done conflicts may happen in locks causing error.

Memory leaks: A memory leak is a situation, where the memory is allocated to the program which
is not freed subsequently. Such a situation can cause ever increasing usage of memory and
resulting in an exceptional halt of program because of the lack of free memory.

Dynamic allocation of data is very crucial in order to store data in heap else it will be stored in
the stack. In order to share data it is good to declare variable as public and use that access
common data.

Don Bosco College, Kottiyam Page 13

 • Freeing the already freed resource
Memory is first allocated and de-allocated. The programmer tries to free the already freed
resource. This is a common form of error.

• NULL dereferencing
Improper initialization, missing the initialization in different paths, or aliases leads to the NULL
reference error.

4. Coding Bugs

The internal structure of the code consists of process and data. While performing testing, one
need to specify execution-oriented test cases based on program logic, coding standards,
programming style, and also checks for complexity of code using techniques like cyclomatic
complexity. Coding bugs may include- non-conformance of code with coding standards;
programming style; syntactical bugs; semantically in-correct code; mathematical and logical
mistakes in the code; ill structured code that is too complex to manage; failure to execute all
independent paths at least once; non-fulfillment of single entry and single exit conditions;
translation errors in converting design into code; documentation errors.

5. Interface, Integration, and System Bugs

A software need to connect with many external systems, internal systems and need to work on
specified or unspecified hardware and operating system. In order to make the software to address
issues related to these aspects, we need to build the software by using appropriate software
architecture and also, build capability to show required behavior by building system level control
and right sequencing to manage resources. While ensuring this, we can come across many bugs
at interface level, integration level, system level, or interoperability level.

a. External Interfaces

The software has to interface with many external applications and hardware in order to carry out
its operations and also, to perform its intended functionality. However, the information about these
external applications and hardware may not be available and also, even if available may not be
complete. In addition, developers have no control on these external components. Even if,
designers try to address them by having robust design with loose coupling and protocols to
establish interfaces, there can still be bugs. The type of bugs may include- wrong protocols;
synchronization related bugs; input and output data inappropriate formats; unavailability of serves;
restricted access or no access etc.

b. Internal Interfaces

Internal interface of software involves establishing interconnectivity among different components

that are within the boundary of software application that is under consideration and also, nature
and type of these components is known to developer. Also, developers have control over these
components. Thus, by knowing these components, at the design level one can provide solution
with appropriate level of coupling, cohesiveness, control and protocols. Some of the bugs that
may occur include- wrong protocol design; inappropriate input and output data formats; failure to

Don Bosco College, Kottiyam Page 14

recover against wrong data; wrong sub-routine calls; synchronization and sequencing related
bugs; wrong parameter passing to initiate and also to exit. Addressing internal interface related
bugs, compared to external interface bugs, is easy since environment is under control and also
interfaces can be ensured by making required changes in programs and parameters.

c. Hardware Architecture

Knowledge about particular hardware and its architecture is very much essential so as to perform
intended functionality. When functionalities of printers are to be performed, we need to send the
instruction of a particular job from desktops or laptops. Similarly when functionalities of mobile
computing devices are to be tested then calls shall be initiated from the handset. However, while
performing these jobs, there can be many bugs like I/O device operation or instruction errors;
inadequate buffer space; I/O device address error; no compatibility among hardware devices;
failure to access the device and so on.

d. Operating System

Operating system related bugs have origin in hardware architecture and interfaces. Operating
system itself may be having some bugs. In addition, there can be missing device drivers because
of which interface related bugs may crop up. Also, there can be errors because of inadequate
understanding of the operating system which may result in problems when we try to build
embedded systems related programs requiring system configuration at OS level by reserving
appropriate buffer space. These bugs can be controlled by having interface specialists to provide
solutions, and also by understanding and defining system level configuration.

e. Software Architecture

Software has to exhibit intended behaviour from functional and non-functional perspective. Non-
functional requirements may include reliability, efficiency, usability, portability, and maintainability.
However, there can be bugs like failure to support required number of users and concurrent users;
slower response time during peak performance; failure to support some other languages;
interoperability related issues etc. All these types of bugs can be addressed at software
architecture level by providing solutions like multi-layered architecture; foreign language support;
providing loose coupling etc.

f. Control and Sequence Bugs

Systems level controls and sequencing play a very crucial role in embedded systems, real time
systems, telecom systems, and mobile computing systems. However there can be bugs like-
failure of execution of events in a required sequence; no activation of any event at the required
time; process initiation even when pre-requisites are not fulfilled; no activation even when pre-
requisite conditions are satisfied etc. In these systems, most of the bugs are related to
synchronization.

Don Bosco College, Kottiyam Page 15

 Synchronization bugs are hard to find bugs with a major impact and may occur where multiple
threads are accessing some common resources. Synchronization bugs are of three types:
Deadlocks, Race conditions, and Live lock.

g. Resource Management Problems

As software systems are becoming more and more complex, there is an ever increasing need to
manage resources that include memory management, availability of links and bandwidth,
availability of server, access to other systems through gateways, and so on. Some of resource
management related bugs are unavailability of required resource; usage of wrong resource;
resource already in use; race conditions in getting resources; unavailability of server;
unavailability of required bandwidth; link failure; denied access to server.

Integration Bugs

Integration bugs are related intra-module and inter-modular interfaces.

Integration bugs can detected by integration testing which verifies inter-module interfaces, critical
external interfaces and user and business workflows and scenarios that would be helpful in
evolving the system. Integration testing includes Functional Testing.

Functional Testing at integration level focuses on verifying components that are basically small
groups of interdependent units that are functionally or logically related. This involves verification
of behavior of the group and also, interfaces that connect the units. This phase is optional, but
recommended in case modules involved are having complex processing areas. Function Test
also exercises the behavior of the component based on specific input including new functionality
and that bug conditions are properly handled.

Test methods used in integration testing and functional testing at integration level include domain
testing, syntax testing, data flow testing.

System Bugs

System bugs cover all types of bugs including both functional and non-functional. Some of the
bugs are missing functionality; wrong functionality; extra functionality; failure to meet required
performance; failure to handle large volumes of information; failure to handle peak volumes of
information; inappropriate documentation; system that is not stable; system that frequently fails
etc. These bugs are directly related to customer and user satisfaction.

6 .Test and Test Design Bugs

Testing
Testers and testing can be bug prone. In testing, especially in business applications, exhaustive
testing is not possible because of many reasons that may include lack of availability of time, effort,
test resources and so on. In addition to this, system tests need code or its equivalent like test
driver or test stub, very complicated scenarios and also, test database with adequate defined data
in it. All these are the potential sources for bugs. Recommended and matured test practice in
order to uncover as many of these bugs as possible is an independent testing. However, this

Don Bosco College, Kottiyam Page 16

practice has a major limitation in the form of wrong interpretation or different interpretation of the
specifications which would result in wrong test cases and scenarios.

1. Test Criteria
Testing helps to detect as many bugs as possible so as to reduce risks of failure of the software.
However, testing does not prove that system is bug free. If testing does not report bugs means it
does not indicate that the system does not have bugs. After performing good enough testing,
system will be released and made operational in a production environment. Here system can
cause many problems related to performance, stability and so which were not seen during system
testing. All these limitations make testing as a process which cannot judge behavior of the system.

Remedies

Test bugs can be addressed by using any of the remedial measures like test debugging, test
quality assurance, test execution and automation, test design automation.

• Test Debugging: Test debugging is all about finding any issues related to test cases, test
coverage and trying to address these issues in order to increase test efficiency.

• Test Quality Assurance: Testing is a structured process which shall monitor and control
skills and competency of testers and also capability of test related processes. Model based
Test Maturity Models (TMM) is in practice which is of use in test quality assurance

• Test Execution Automation: Whenever there is a need to carry out many rounds of testing
on the same system, we can sense the possibility of test execution automation. Here, by
selecting appropriate commercial or open source testing tools, tests that are designed by
testers can be recorded in these tools and the same can be played back so as to complete
testing in a shorter period.

• Test Design Automation: Slowly but steadily more and more tools are getting into test design
automation. These tools are of use in automating test design at code level and also, at system
level.

7. Testing and Design Style

Bad design and bad code lead to bugs. Bugs that have origin in design are hard to find and
address. Thus, in order to carry out effective testing, good design and good code is a prerequisite.
If testing is being done on bad design and bad code, there will be new stream of bugs in every
round of testing showing ever increasing new bugs and never ending testing. This trend of
reporting more and more bugs will beat the very objective of testing on ensuring stable product
with lesser risks, and also increased confidence on using it. Thus good testing requires good
design and good code. Good designs not only inhibit or filter the bugs before they occur and
thereby reduce overall effort of software development and reduce rework effort. In brief, it is
always god recommend redesigning rather carrying out testing on bad design and code.

Don Bosco College, Kottiyam Page 17

 ***************************************************************************

Consequences of Bugs
Software systems are part of our daily life. Each of these software systems is a collection of
computer programs, procedures, and possibly associated documentation and data pertaining to
the operation of a computer system. Many a times these software systems do not work as
expected. When this happens we say that the software is buggy. These bugs in software systems
and system occur because of many reasons. Some of these bugs might have occurred because
of human mistakes, that is, humans involved in software development are fallible. Other bugs
might have been caused because of bad assumptions made during software development.
Software systems that do not work as per expectations carry some level of risk and have a varying
impact. When a risk occurs it may cause trivial issues or can be costly or damaging like loss of
money, time or business credibility, loss of life. Software testing tries to uncover as many
mistakes as possible so that customers and users shall not face problems because of existing
mistakes in software, post release debugging which is very expensive can be reduced, stake
holders get appropriate information to make decisions about software quality and release, and to
help the stake holders with the risks of the products.

During testing and reviews, as many bugs as possible shall be detected so as to reduce the
impact of such bugs. However it is not practically possible to detect and to address all these bugs.
Thus we need some criteria to prioritize and address these bugs. This requires an understanding
on the importance of bugs and their consequences on the software.

• The Importance of Bugs

• The Implications of Bugs- Consequences

• Flexible Severity Vs. Absoluteness

1. The Importance of Bugs

All bugs in software or its components need not be considered with same importance but
depending on frequency of occurrence, correction costs, installation costs, and consequences
each bug shall be given importance so as to decide on which bug shall be addressed first.

A reasonable metric for bug importance is:

Bug Importance in USD = Frequency * (Correction Cost + Installation Cost + Consequences Cost)

Here frequency does not depend on environment where the system works. However Correction
Cost, Installation Cost, and Consequences Cost are environment dependent.

Frequency: Frequency of bug provides information on how often a particular bug type occurs.
Higher the frequency of occurrence of bug type more shall be our focus on it.

Don Bosco College, Kottiyam Page 18

Correction Cost: A Correction cost is total costs incurred towards correcting the bug after it has
been reported. Correction cost basically involves two components- the cost of detecting the bug
and the cost of correcting it. Costs of correcting the bug depends on the phase of development
cycle at which the bug is discovered. Later is the phase in development cycle of bug discovery
higher will be the correction costs. Correction cost also depends on system size and complexity.
The larger the system size higher will be the cost of correction. This is because of the fact that
when the system is larger, the amount of time and effort required to disassemble the system,
locating the bug, correcting it, integrating it is more.

Installation Cost: Installation cost is the cost of distributing and installing the software at different
locations after the fix.

Consequences Cost: Consequences cost is the total cost incurred towards implication or
damage of the bug on business, human life, or an organization.

2. The Implications of Bugs- Consequences

Consequences of the bugs depend on severity of the bug, its impact of the severity on the
behavior of system, and damage caused by it. The consequences of the bug are subjective
measure depending on the software and the system. However following classes for
consequences on the scale of 1 to 4 are common in practice:

• Mild (Cosmetic): Bugs that do not have any effect on system’s operation and
performance. (differing alignments, typographic errors, etc)

• Minor: Bugs that can cause small or negligible consequences for the system. (round-off
and truncation errors, inconsistency in look and feel, etc)

• Major: Bugs that could cause malfunctioning of the system with manageable costs and
user satisfaction (losing some important data, slow performance of the system than required, etc)

• Catastrophic: Bugs that can cause very serious effects with serious consequences in
terms cost and customer satisfaction (system crash or show stoppers, security breaches resulting
in access to classified and confidential data etc.)

These consequences can be mapped to Cosmetic (Mild); Minor (Moderate, annoying, Disturbing);
Major (Serious, Very Serious, Extreme, Intolerable); Catastrophic (Catastrophic, Infectious).

PATH TESTING

Path Testing is the name given to a family of test techniques based on judiciously selecting
a set of test paths through the program. If the set of paths are properly chosen then we
have achieved some measure of test thoroughness.

Don Bosco College, Kottiyam Page 19

For example, pick enough paths to assure that every source statement has been executed
at least once.

• Path testing techniques are the oldest of all structural test techniques.
• Path testing is most applicable to new software for unit testing.
• It is a structural technique.
• It requires complete knowledge of the program's structure.
• It is most often used by programmers to unit test their own code.
• The effectiveness of path testing rapidly deteriorates as the size of the software
aggregate under test increases.

THE BUG ASSUMPTION:

The bug assumption for the path testing strategies is that something has gone wrong with
the software that makes it take a different path than intended.

As an example "GOTO X" where "GOTO Y" had been intended.

Structured programming languages prevent many of the bugs targeted by path testing: as
a consequence the effectiveness for path testing for these languages is reduced and for
old code in COBOL, ALP, FORTRAN and Basic, the path testing is indispensable.

CONTROL FLOW GRAPHS:

The control flow graph or flow graph is a graphical representation of a program's control
structure. It uses the elements named process blocks, decisions, and junctions. The flow
graph is similar to the earlier flowchart, with which it is not to be confused.

Flow Graph Elements: A flow graph contains four different types of elements.

(1) Process Block

(2) Decisions
(3) Junctions
(4) Case Statements

1. Process Block:

A process block is a sequence of program statements uninterrupted by either

decisions or junctions. It is a sequence of statements such that if any one of statement
of the block is executed, then all statement thereof is executed. Formally, a process
block is a piece of straight line code of one statement or hundreds of statements. A

Don Bosco College, Kottiyam Page 20

process has one entry and one exit. It can consists of a single statement or
instruction, a sequence of statements or instructions, a single entry/exit subroutine,
a macro or function call, or a sequence of these.

2. Decisions:

A decision is a program point at which the control flow can diverge. Machine language
conditional branch and conditional skip instructions are examples of decisions. Most
of the decisions are two-way but some are three way branches in control flow.

3. Case Statements:

A case statement is a multi-way branch or decisions.

Examples of case statement are a jump table in assembly language, and the
PASCAL case statement.

From the point of view of test design, there are no differences between Decisions
and Case Statements

4.Junctions:

A junction is a point in the program where the control flow can merge.

Examples of junctions are: the target of a jump or skip instruction in ALP, a label that is a target
of GOTO.

Don Bosco College, Kottiyam Page 21

CONTROL FLOW GRAPHS Vs FLOWCHARTS:

• A program's flow chart resembles a control flow graph.

• In flow graphs, we don't show the details of what is in a process block.
• In flow charts every part of the process block is drawn.
• The flowchart focuses on process steps, where as the flow graph focuses on
control flow of the program.
• The act of drawing a control flow graph is a useful tool that can help us clarify the control
flow and data flow issues.

An improper translation from flowgraph to code during coding can lead to bugs, and
improper translation during the test design lead to missing test cases and causes
undiscovered bugs.

FLOWGRAPH AND FLOWCHART GENERATION:

Flowcharts can be

• Handwritten by the programmer.

Don Bosco College, Kottiyam Page 22

• Automatically produced by a flowcharting program based on a mechanical analysis of
the source code.
• Semi automatically produced by a flow charting program based in part on structural
analysis of the source code and in part on directions given by the programmer.
• There are relatively few control flow graph generators.

PATH TESTING - PATHS, NODES AND LINKS:

Path: a path through a program is a sequence of instructions or statements that starts at

an entry, junction, or decision and ends at another, or possibly the same junction, decision,
or exit.

A path may go through several junctions, processes, or decisions, one or more times.

Paths consist of segments.

o The segment is a link - a single process that lies between two nodes.
o A path segment is succession of consecutive links that belongs to some path.
o The length of path measured by the number of links in it and not by the number of the
instructions or statements executed along that path.
o The name of a path is the name of the nodes along the path.

FUNDAMENTAL PATH SELECTION CRITERIA:

There are many paths between the entry and exit of a typical routine. Every decision
doubles the number of potential paths. And every loop multiplies the number of potential
paths by the number of different iteration values possible for the loop.

Defining complete testing:

1 Exercise every path from entry to exit

2 Exercise every statement or instruction at least once

3 Exercise every branch and case statement, in each direction at least

once

If prescription 1 is followed then 2 and 3 are automatically followed. But it is impractical for
most routines. It can be done for the routines that have no loops, in which it is equivalent to
2 and 3 prescriptions.

Don Bosco College, Kottiyam Page 23

 PATH TESTING CRITERIA:

Any testing strategy based on paths must at least both exercise every instruction and take
branches in all directions. A set of tests that does this is not complete in an absolute sense,
but it is complete in the sense that anything less must leave something untested. So we
have explored three different testing criteria or strategies out of a potentially infinite family
of strategies.

1. Path Testing (Pinf):

• Execute all possible control flow paths through the program: typically, this is
restricted to all possible entry/exit paths through the program.
• If we achieve this prescription, we are said to have achieved 100% path coverage.
This is the strongest criterion in the path testing strategy family: it is generally impossible
to achieve.

2. Statement Testing (P1):

• Execute all statements in the program at least once under some test. If we do
enough tests to achieve this, we are said to have achieved 100% statement coverage.
• An alternate equivalent characterization is to say that we have achieved 100% node
coverage. We denote this by C1.
• This is the weakest criterion in the family: testing less than this for new software is
unconscionable (unprincipled or cannot be accepted) and should be criminalized.

3. Branch Testing (P2):

• Execute enough tests to assure that every branch alternative has been exercised at
least once under some test.
• If we do enough tests to achieve this prescription, then we have achieved 100% branch
coverage.
• An alternative characterization is to say that we have achieved 100% link coverage.
• For structured software, branch testing and therefore branch coverage strictly includes
statement coverage.
• We denote branch coverage by C2.

PREDICATES, PATH PREDICATES AND ACHIEVABLE PATHS:

PREDICATE

The logical function evaluated at a decision is called Predicate. The direction taken
at a decision depends on the value of decision variable.

Some examples are: A>0, x +y>=90.......

Don Bosco College, Kottiyam Page 24

 PATH PREDICATE

A predicate associated with a path is called a Path Predicate. It is a sequence of

predicates whose truth values will cause the routine to take a specific path.

For example, "x is greater than zero", "x+y>=90", "w is either negative or equal to 10 is
true"

MULTIWAY BRANCHES:

The path taken through a multiway branch such as a computed GOTO's (FORTRAN),
case statement (pascal), or jump tables (assemble language) cannot be directly
expressed in TRUE/FALSE terms. Although, it is possible to describe such alternatives
by using multi valued logic, an expedient (practical approach) is to express multiway
branches as an equivalent set of if..then..else statements.

For example a three way case statement can be written as: If case=1 DO A1 ELSE (IF
Case=2 DO A2 ELSE DO A3 ENDIF)ENDIF.

Predicate Expression

1. PREDICATE INTERPRETATION:

The simplest predicate depends only on input variables.

For example if x1,x2 are inputs, the predicate might be x1+x2>=7, given the values of
x1 and x2 the direction taken through the decision is based on the predicate is
determined at input time and does not depend on processing.

Another example, assume a predicate x1+y>=0 that along a path prior to reaching this
predicate we had the assignment statement y=x2+7. although our predicate depends on
processing, we can substitute the symbolic expression for y to obtain an equivalent
predicate x1+x2+7>=0.

The act of symbolic substitution of operations along the path in order to express the
predicate solely in terms of the input vector is called predicate interpretation.
Sometimes the interpretation may depend on the path; for example,

INPUT X

ON X GOTO A, B, C, ...

A: Z := 7 @ GOTO HEM

B: Z := -7 @ GOTO HEM

Don Bosco College, Kottiyam Page 25

 C: Z := 0 @ GOTO HEM

.........

HEM: DO SOMETHING

.........

HEN: IF Y + Z > 0 GOTO ELL ELSE GOTO EMM

The predicate interpretation at HEN depends on the path we took through the first
multiway branch. It yields for the three cases respectively, if Y+7>0, Y-7>0, Y>0.

The path predicates are the specific form of the predicates of the decisions along
the selected path after interpretation.

2.INDEPENDENCE OF VARIABLES AND PREDICATES:

The path predicates take on truth values based on the values of input variables, either
directly or indirectly. If a variable's value does not change as a result of processing, that
variable is independent of the processing. If the variable's value can change as a result
of the processing, the variable is process dependent .A predicate whose truth value can
change as a result of the processing is said to be process dependent and one whose
truth value does not change as a result of the processing is process independent.
Process dependence of a predicate does not always follow from dependence of the input
variables on which that predicate is based.

CORRELATION OF VARIABLES AND PREDICATES:

• Two variables are correlated if every combination of their values cannot be

independently specified.
• Variables whose values can be specified independently without restriction are called
uncorrelated.
• A pair of predicates whose outcomes depend on one or more variables in common
are said to be correlated predicates.

For example, the predicate X==Y is followed by another predicate X+Y == 8. If we

select X and Y values to satisfy the first predicate, we might have forced the 2nd
predicate's truth value to change.

• Every path through a routine is achievable only if all the predicates in that routine
are uncorrelated.

3.PATH PREDICATE EXPRESSIONS:

Don Bosco College, Kottiyam Page 26

 A path predicate expression is a set of boolean expressions, all of which must be
satisfied to achieve the selected path.

▪ Example: X1+3X2+17>=0
X3=17

X4-X1>=14X2

Any set of input values that satisfy all of the conditions of the path predicate
expression will force the routine to the path. Sometimes a predicate can have an OR
in it.

Example:

A: X5 > 0
E: X6 < 0
B: X1 + 3X2 + 17 >= 0
B: X1 + 3X2 + 17 >= 0
C: X3 = 17
C: X3 = 17
D: X4 - X1 >= 14X2
D: X4 - X1 >= 14X2

PREDICATE COVERAGE:

Compound Predicate: Predicates of the form A OR B, A AND B and more complicated

Boolean expressions are called as compound predicates. Sometimes even a simple
predicate becomes compound after interpretation.

Example: the predicate if (x=17) whose opposite branch is if x.NE.17 which is equivalent
to x>17 . Or. X<17.

Predicate coverage is being the achieving of all possible combinations of truth values
corresponding to the selected path have been explored under some test. Predicate
coverage is stronger than branch coverage .If all possible combination of all predicates
under all interpretations are covered, we have equivalent of total path testing.

TESTING BLINDNESS:

Testing Blindness is a pathological (harmful) situation in which the desired path is

achieved for the wrong reason. There are three types of Testing Blindness:

1. Assignment Blindness:

Don Bosco College, Kottiyam Page 27

Assignment blindness occurs when the buggy predicate appears to work correctly
because the specific value chosen for an assignment statement works with both
the correct and incorrect predicate.

For Example:

Correct Buggy

X = 7 X = 7
........ ........
if Y > 0 then ... if X+Y > 0 then ...

If the test case sets Y=1 the desired path is taken in either case, but there is still
a bug.

2.Equality Blindness:

Equality blindness occurs when the path selected by a prior predicate results in a
value that works both for the correct and buggy predicate.

For Example:

Correct Buggy

if Y = 2 then if Y = 2 then
........ ........
if X+Y > 3 then ... if X > 1 then ...

The first predicate if y=2 forces the rest of the path, so that for any positive value
of x. the path taken at the second predicate will be the same for the correct and
buggy version.

3.Self Blindness:

Self blindness occurs when the buggy predicate is a multiple of the correct
predicate and as a result is indistinguishable along that path.

For Example:

Correct Buggy

Don Bosco College, Kottiyam Page 28

 X = A X = A
........ ........
if X-1 > 0 then ... if X+A-2 > 0 then ...

The assignment (x=a) makes the predicates multiples of each other, so the
direction taken is the same for the correct and buggy version.

PATH SENSITIZING:

ACHIEVABLE AND UNACHIEVABLE PATHS:

o We want to select and test enough paths to achieve a satisfactory notion of test
completeness such as C1+C2(Node Coverage+ Branch Coverage).
o Extract the programs control flowgraph and select a set of tentative covering
paths.
o For any path in that set, interpret the predicates along the path as needed to
express them in terms of the input vector. In general individual predicates are
compound or may become compound as a result of interpretation.
o Trace the path through, multiplying the individual compound predicates to
achieve a boolean expression such as

(A+BC) (D+E) (FGH) (IJ) (K) (l) (L).

Where the term in parentheses are the compound predicates met each decision along
the path and each letter(A,B,C,….)stands for simple predicates.

o Multiply out the expression to achieve a sum-of-products form:

ADFGHIJKL+AEFGHIJKL+BCDFGHIJKL+BCEFGHIJKL

o Each product term denotes a set of inequalities that if solved will yield an input
vector that will drive the routine along the designated path.
o Solve any one of the inequality sets for the chosen path and you have found a
set of input values for the path.

If you can find a solution, then the path is achievable. If you can’t find a solution to any
of the sets of inequalities, the path is un achievable. The act of finding a set of solutions
to the path predicate expression is called PATH SENSITIZATION.

HEURISTIC PROCEDURES FOR SENSITIZING PATHS:

Don Bosco College, Kottiyam Page 29

This is a workable approach, instead of selecting the paths without considering how to
sensitize, attempt to choose a covering path set that is easy to sensitize and pick hard to
sensitize paths only as you must to achieve coverage.

1. Identify all variables that affect the decision.

2. Classify the predicates as dependent or independent.
3. Start the path selection with un correlated, independent predicates.
4. If coverage has not been achieved using independent uncorrelated
predicates, extend the path set using correlated predicates.
5. If coverage has not been achieved extend the cases to those that involve
dependent predicates.
6. Last, use correlated, dependent predicates.

For each path selected above ,list the input variables(dependent, independent or
correlated) corresponding to the predicates required to force the path.

PATH INSTRUMENTATION:

Path instrumentation is done to confirm that the outcome was achieved by the intended
path.

• Co-incidental Correctness: The coincidental correctness stands for achieving

the desired outcome for wrong reason.

Figure : Coincidental Correctness

Don Bosco College, Kottiyam Page 30

The above figure is an example of a routine that, for the (unfortunately) chosen input value
(X = 16), yields the same outcome (Y = 2) no matter which case we select. Therefore, the
tests chosen this way will not tell us whether we have achieved coverage. For example, the
five cases could be totally jumbled and still the outcome would be the same.

Path Instrumentation is what we have to do to confirm that the outcome was achieved
by the intended path.

TYPES OF INSTRUMENTATION METHODS INCLUDE:

1.Interpretive Trace Program:

An interpretive trace program is one that executes every statement in order and
records the intermediate values of all calculations, the statement labels traversed
etc .If we run the tested routine under a trace, then we have all the information we
need to confirm the outcome and, furthermore, to confirm that it was achieved by
the intended path. The trouble with traces is that they give us far more information
than we need. In fact, the typical trace program provides so much information that
confirming the path from its massive output dump is more work than simulating
the computer by hand to confirm the path.

2.Traversal Marker or Link Marker:

A simple and effective form of instrumentation is called a traversal marker or link

marker. Name every link by a lower case letter. Instrument the links so that the
link's name is recorded when the link is executed. The succession of letters
produced in going from the routine's entry to its exit should, if there are no bugs,
exactly correspond to the path name.

Figure :Single Link Marker Instrumentation

Don Bosco College, Kottiyam Page 31

 • Why Single Link Markers aren't enough: Unfortunately, a single link
marker may not do the trick because links can be chewed by open bugs.

Figure : Why Single Link Markers aren't enough.

We intended to traverse the ikm path, but because of a rampaging GOTO in the
middle of the m link, we go to process B. If coincidental correctness is against us, the
outcomes will be the same and we won't know about the bug.

3.Two Link Marker Method:

The solution to the problem of single link marker method is to implement two
markers per link: one at the beginning of each link and on at the end. The two
link markers now specify the path name and confirm both the beginning and
end of the link.

o Figure : Double Link Marker Instrumentation.

Don Bosco College, Kottiyam Page 32

 • Link Counter: A less disruptive (and less informative) instrumentation
method is based on counters. Instead of a unique link name to be pushed into
a string when the link is traversed, we simply increment a link counter. We
now confirm that the path length is as expected. The same problem that led
us to double link markers also leads us to double link counters.

University Questions 2017

Section A(1 mark)

1. What do you mean by testing software?

2. What do you mean by logical error?

3. What do you mean by a test case?

4. What is flow graph?

5. What is the purpose of debugging?

6. What do you man by control flow graph?

Section B (2 marks)

1. What is branch testing?

Section C (4 marks)

1. Write short note on coding bugs?

2. Differentiate functional testing with structural testing.

3. Explain domain error.

Section D (15 marks)

1. Describe the dataflow testing.

Don Bosco College, Kottiyam Page 33

Don Bosco College, Kottiyam Page 34