Software Testing

UNIT: 3 Static Testing Techniques

Chapter Objectives
 What is static testing?
 Advantages of static testing
 Difference between static testing and dynamic testing
 Review mechanisms and formal review process
 Checklists
 Static code review and coding guidelines for C and Java
 Static analysis tools
Prevention is better than cure. To find out the defects at early stages of software
development is much better than to find out the failures and realize that there were
defects in specifications or design or code. An excellent mechanism for preventing
failures is static testing. In static testing, a work product is reviewed manually. For
example, a source code is reviewed without executing the code. In this chapter, we will
study the details of static testing and how to carry out the code review. We will also
discuss the tools that help in carrying out the static testing.
3.1 Static Testing
Without executing the program, the 'testing' carried out is called static testing. In other
words, in static testing, the work product (for example, the code) is analyzed and checked
for errors.
NOTE: In dynamic testing, the software is compiled and executed whereas in static
testing (or static analysis), the code is not executed.
NOTE: Static testing is also known as static analysis or desk checking.
Many programmers and managers have found that by doing the static testing before the
dynamic testing, many errors can be uncovered easily. Though, static testing of the code
is very common and it can be applied to any work product. There are two ways in which
static testing is carried out:
 Manual review of work products (SRS document, design document, source code,
test plan, test cases, test scripts etc.); or
 Using static analysis tools
3.1.1 Advantages of Static Testing
Static testing is done to find defects during the entire development life cycle, i.e. in
different phases of development:
 You can take the specification document and check whether each and every
requirement of the user is specified. You can also check whether the source code
implements each and every requirement.
 You can take the design document and check whether the design will take care of
all the specifications in the SRS document. You can also verify whether the
design is really implementable or it is just a theoretical design.

B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 1

 Software Testing

 You can take the source code and check whether the source code implements all
the specifications. You can also verify whether the design is converted into code
correctly.
 If the code is not written as per organization's coding standards, static analysis of
code reveals this.
 If standards are not followed for implementing a particular functionality (for
example, implementing a protocol as per standards; not complying to
national/international compliance requirements such as HIPAA for medical
software), then static analysis reveals this anomaly.
 It is easy to find incorrect interface specifications, interoperability specifications.
 It is easy to find out the missing requirements (for example, if the database engine
is not specified in the requirements or design)
 Sometimes, you need to do code optimization i.e., to modify the code to reduce
execution time or to reduce memory requirement. In such a case, you need to
manually review the code and check where the code has to be modified.
So, the advantages of static testing are as follows:
 Incorrect specifications and missing specifications can be found at an early stage
of development and hence lot of rework is reduced.
 Incorrect design can be found early and hence life cycle time is reduced.
 Specifications can be checked against the code so that if some requirements are
not implemented, they are detected early.
 It can be ensured that the code is as per requirements, and coding guidelines and
standards are followed so that maintainability of the software becomes easier.
 As a result of the above, time, effort and money required for the total
development life cycle will be reduced and the productivity of the employees will
increase.
3.2 Manual Reviews
In static testing, manual reviews are the most effective mechanism to find out the defects.
The manual reviews can be done on any of the work products such as:
 SRS document
 Design document
 Source code
 Test plan
 Acceptance test plan
 Test cases and test scripts
 User manual

B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 2

 Software Testing

3.2.1 Formal Review Process

In formal reviews, reviews are done through a formal meeting. The project manager will
generally plan formal reviews for various work products. (A formal review process
consists of the following steps:
Define Review Objectives
To start with, the manager has to define, what are the objectives of the review are. The
objectives can be:
 To detect the defects,
 To detect the defects and discuss how to rectify them
 To assign responsibility to persons for rectifying the defects
Identify the Review Team
The project manager has to form a review team consisting of:
 Author(s): The author(s) of the work product which is going to be reviewed.
 Reviewers: Two or more reviewers who have the necessary application domain
knowledge, programming language knowledge. The reviewers can give their
expert opinion and find defects objectively.
 Secretary: A person whose job is just to record the proceedings of the meeting, to
note down the important points discussed and the follow-up actions need to taken.
 Moderator: The person who steers the review meeting. During the meeting, it is
likely that there will be different points of view, and sometimes the author and
reviewers may argue with each other. In such a case, the moderator has to
moderate the discussion.
 Manager: The manager identifies the objectives, plans the review meetings
provides the necessary infrastructure and resources and reviews the outcomes the
meeting.
Plan the Meeting
Identifying the work product(s) to be reviewed, identifying the people to be involved and
their roles and responsibilities.
 Preparatory activities: Distribution of the relevant documents to the participants,
informing them the objectives of the meeting and the agenda. Each participant has
to do the necessary preparation for the meeting by going through the documents.
 Actual review meeting: A designated person will explain the work product or do
the code walkthrough by explaining line by line to all the members. Necessary
issues will be discussed, the minutes of the meeting are recorded and the
coordinator (or project manager) will inform the action points to be taken up later
after the meeting
 Rework: The action points are studied and the defects are rectified by the author
of the work product
 Follow-up: Whether the action points are completed or not, is checked through a
follow-up meeting.
B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 3
 Software Testing

Variations to these formal review meetings are known with different names such as:
 Informal reviews
 Walkthroughs
 Inspections
3.2.2 Informal Reviews
It will not be possible for the project manager/project leader to review each and every
line of code written by the engineers/programmers. In informal review, the author and
his/her one or more colleague will sit together and go through the work product and try to
find defects in the work product. The defects found will be recorded and rectified later.
Such informal reviews are very effective if they are peer reviews, i.e. engineers at the
same level of hierarchy carry out the review. This is very easy and effective way of
finding defects.
3.2.3 Walkthroughs
In code walkthrough, a review meeting is organized in which the author of the work
product coordinates the meeting. It can be done formally or informally. The meetings are
attended by one or two experts, peers and a secretary to note down the important issues
discussed. The author explains the details and each aspect are discussed by the group. If
the walkthrough is done formally, minutes of the meeting are recorded.
3.2.4 Inspections
The inspections are like formal reviews. However, the review is done by peers’ (people
working at the same level). One of the team members should be a moderator who leads
the inspection process. The inspections are done generally with the help of a checklist
(coding checklist, design checklist etc.). List of metrics to be collected for the specific
process/product are also identified. Minutes of the meeting are recorded and followed up.
3.3 Making Reviews Successful
For review meetings to succeed, the manager and all the team members should keep in
mind that:
 Review is done to find defects, not to find out who did the mistake.
 While obtaining productivity metrics (such as how many defects were found per
1000 lines of code), the focus should be done on the average value for the total
team rather than for individual team members.
 The moderator has to ensure that members discuss issues, but not argue.
 The team members should not get emotionally attached to their work.
 The objectives of the review meeting should be clearly defined.
 The review team should have persons with expertise and those who look at things
objectively.
 Every member of the review committee should go prepared for the meeting.
 Checklists and coding guidelines should be used in the review.
 Project manager should provide the necessary resources for the review meetings.
 The reviews should help in improving the overall software development process.
B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 4
 Software Testing

3.4 Checklists
During the static testing of different work products (and also during dynamic testing),
checklists play a very important role. For every work product, a checklist has to be
prepared and the work product has to be checked thoroughly by the review team by using
the checklist.
SRS Checklist
As per IEEE standard (IEEE 1994), a good SRS document should have the following
characteristics:
 Unambiguous: Is there any ambiguity in the SRS document because of the
natural language used?
 Complete: Are the user requirements completely covered in the document?
 Verifiable: Is every functional requirement and non-functional requirement
specified in the document verifiable?
 Consistent: Is there any inconsistency in different portions of the software?
 Modifiable: Is it easy to make changes to the SRS document?
 Traceable: Is it possible to correlate each requirement with the corresponding
design, test case etc.?
 Usable: Is the SRS document usable during the remaining stages of development?
 Validated: Is the SRS document validated by the client?
Design Checklist
 Is every functional requirement taken into account?
 Are the performance requirements met?
 Are the design constraints/limitations recorded?
 What assumptions are made and are they OK?
 Are the external interfaces specified?
 Is the design modular?
 Is the prototype of user interface demonstrated to the user and feedback obtained?
 Are data structures identified?
 Are the sizes of data files specified?
 Are the chosen algorithms OK?
 Is the detailed design for each module done?
 Is the module interconnection specified?
 Is error handling taken care?
 Is the help engine designed and integrated?

B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 5

 Software Testing

GUI Checklist
 Is the application starting when the icon is double clicked?
 Is the application starting twice when the icon is double clicked twice? (It should
not).
 Is the caption of the main window of the application having the same name as that
of the icon?
 Is every window having the correct title? (Instead of form1, form2, screen1 etc.)
 Do all the screens have consistent look and feel?
 Is each field validated in every screen?
 If wrong input is entered in a field, is an error message getting displayed?
 Is " (double quote) or ‘ (single quote) allowed in a text entry box?
 Does each push button have a short cut key?
Web Site Checklist
 Does the web site work exactly in the same way for all web browsers?
 Is every link checked?
 Is the content getting downloaded in maximum 10 seconds? (Beyond it, the user
loses patience).
 Is every page printer-friendly?
 Is there a site map?
 Is there a search option?
 Is accessibility for disabled provided?
 Is any plug-ins required, if so, is the option for downloading provided?
 Is there audio content? If so, what resources are required on the client system for
the audio to play? Is that indicated in the site?
3.5 Formal Code Reviews
Among all the work products, the source code is the most important work product that
must undergo a formal review. The process of holding formal code review meetings is
same as discussed above. The project manager identifies the objectives and participants.
The participants include the programmers, the expert reviewers, moderator and a
secretary. The programmer will explain the source code and it is reviewed to check:
 Whether coding guidelines are followed or not.
 Completeness in implementing the functionality.
 Whether there is any unreachable code.
 Whether the code is maintainable--whether enough online documentation is
available or not.

B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 6

 Software Testing

 Whether the code is written by the programmer or copied from public domain
(openly available) software (using "copy and paste" technology).
 Whether the code is portable, if portability is a requirement.
 Whether the code is written for easy testability and whether the debugging code
has been left behind in the code or not.
 Whether performance issues are taken care and whether the code has to be
optimized
The important outcomes of the meeting are recorded and follow-up action to be taken is
identified.
3.5.1 Coding Guidelines
In the formal code review meetings, it must be checked whether the programmers are
following the coding guidelines defined in the organization. If the guidelines are
followed, testing and maintenance will be very easy. Unfortunately, many programmers
do not follow any discipline while writing the code. This leads many maintenance
problems-nobody would like to maintain the code written by someone else.
Every organization has to develop a set of guidelines for all the programmers to follow
that the code can be maintained easily. This aspect is discussed in this section.
3.5.2 Programming Style
Every programmer has to follow certain guidelines while doing the coding. Some such
representative guidelines are given below:
 The layout of the code should be in such a way that it is easy to read. Proper
indentation of the code is required. After the code is finalized, it can be passed
through a utility (such as C beautifier for C language) which will give the
necessary indentation.
 Names of files, functions and variables should not be cryptic but meaningful.
 Function size to be limited to 40/50 lines.
 Module size to be limited based on structure.
 Deep nesting to be avoided.
 Exceptions/errors should be handled by using the code, to make the code robust.
 Single entry, single exit control structures should be used and 'goto' must be
avoided.
 User defined types to be used to increase readability (such as enum, typedef).
 Each file must have a header containing the name of the programmer, date on
which the code was written, and the revision history—when the code was revised.
 The functionality of each module/function must be explained briefly.
 The input and output parameters for each function/method must be explained.
 Assumptions made during the coding/design to be mentioned.

B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 7

 Software Testing

3.5.3 C Coding Guidelines

All the project team members need to follow some guidelines while doing the coding.
Every organization should have a document called 'coding guidelines/standards' for each
programming language. Every engineer needs to follow these guidelines.
The guidelines specify simple rules to be followed by all the engineers. Some important
guidelines are given below:
 For every project, a folder should be maintained that contains all the source code
files. The folder name should be the name of the project. This folder should have
a readme file that gives the list of files and the contents of the file.
 The backup of the project folder should be taken every day so that, at most one
day's work only is lost, in case there is a major failure of the systems.
 The filenames should reflect the functionality of the source code given in that file.
 Every file should contain a header that gives the copyright information, name of
the file, author of the code and revision history as shown below:
/* Copyright Dr. Prasad, 2006 */
/* Name of the author: Dr. Prasad */
/* this is a header file containing global constants */
/* version 1.0 */

 Identifiers such as variables, structure/union members, functions and macros

should have meaningful names. However, temporary variables such as loop
counters can be given names such as i, j, k, etc. Strings can have a prefix of s, and
pointers can have a prefix of p.
 On-line documentation (comments) should be relevant. A good commenting style
is to have the comment in the same line as the code:
int max_temperature = 50; /* threshold on temperature is 50 degrees*/
 Constants and macros should always be in upper case.
#define PI 3.1415
 Proper indentation helps readability and understandability of the code. Simple
rules that are followed in normal typing need to be followed while coding as well.
Comma (,) and Semi-colon (;) need to be followed by a single space. There
should be no space between the unary operator and the operand. For binary
operators, the operator should have a space before and after. The following code
snippets demonstrate these indentation guidelines:
-b not - b (unary operator)
a=0 not a=0 or a =0 or a= 0 if (binary operator)

if(d > 0) {
root = sqrt();
}

B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 8

 Software Testing

if(d > 0)
root1 = -2 * a / d;
root2 = 2 * a/d;
}
else {
printf(“No root\n");
}
do {
statements;
} while (x > 0);
 Whenever changes are made to a source file, modify the header indicating the
date of modification and why the modification has been done.
/* Revision history */
/* Date: 17 July 2006 max temperature initialization value changed to 55
as per client requirement */
 It is advisable to use the source code configuration software (sccs or rcs, or any
other equivalent software) if there are a large number of source code files to be
maintained.
 During the course of development, the code written by one engineer should be
given to another engineer who has to check whether the coding guidelines are
being followed or not.
3.5.4 Code Optimization
Code optimization can be done to make the execution faster. Some important code
optimization guidelines are given below. While carrying out the code review, you need to
keep these guidelines in mind:
 Eliminate dead code: Dead code is that portion of the code that will not to
execute at all. Sometimes programmers left dead code in the program. Therefore
need to find and eliminate dead code. Profilers help in elimination of dead code.
 Remove unnecessary debugging code: Lot of code is written during the
development time for debugging purposes. Unnecessary debugging code needs to
be removed
 Avoid recursion: Recursive functions require a large stack resulting in higher
memory requirement. For example, instead of using recursion for calculating a
factorial of a number, a better approach is to use a lookup table that will pick up
the factorial
 Avoid floating point operations: If necessary, floating-point operations can be
converted into fixed-point operations.
 Use unsigned integers: Use unsigned integer variables wherever possible.
 Avoid large library routines: To the extent possible, large library routines need
to be avoided

B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 9

 Software Testing

 Remove loop-invariant code: The code that has no effect on the loop counter is
called the loop-invariant code. Consider the example:
for (i=0; i < 10; ++i)
{
x = 1.0/b;
y=x+i;
}
In this code, the statement x=1.0/b; is loop-invariant because the value of x is not
dependent on the value of i. Hence, it has to be removed.

3.5.5 Java Coding Guidelines

This section gives the guidelines to be followed by all software engineers while doing
programming in java. These guidelines have been framed to ensure that the code can be
understood easily by persons other than the original author of the software for easier
maintenance.
Backup Policy and Schedules during Development Phase
At the end of each day, the software has to be backed up in the specified folder on the
server. This ensures that at most only one day’s effort is lost in case of a system failure.
Project Folder
Each software developer will have a folder with the name of the project in his/her
directory on his/her machine in the root directory. In this folder, a file with the name
‘readme’ should be present which gives a description of all the sub-folders and file names
in the folder corresponding to the project. The version number of the software should be
reflected as a part of the filename. For example, quest1.0 should be the file name for the
quest project version 1.0.
All the names of the directories and files should be meaningful indicating the module
name or the unit name. The 'readme' file should be in the format:
Filename description status (tested ok, testing in progress)
Once a program module tested and found OK, the 'readme' file should be updated with
the new status.
Java Coding Conventions
The header should be in javadoc format.
Use documentation comments immediately before declarations of interfaces, classes, and
member functions. Documentation comments are processed by javadoc.
/* Subscriber: A subscriber is a person who uses
The IVR system
@author KVKK Prasad */

The important javadoc tags are given below:

 @author name: This is used for classes and interfaces to indicate the author(s) of
the code. One tag has to be used per author.

B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 10

 Software Testing

 @deprecated: This is used for classes and member functions to indicate that the
API for the class has been depreciated and should not be used any longer.
 @exception name description: This is used for member functions to describe the
exceptions that a member function throws.
 @param name description: This is used for member functions to describe a
parameter passed to a member function, including its type/class and its usage.
 @return description: This is used for member functions to describe the return
value, if any, of a member function. The type/class and the potential uses of the
return value should be indicated.
 @since: This is used for classes and member functions to indicate how long the
item has existed since JDK 1.1.
 @see ClassName: This is used for classes, interfaces, member functions and
fields. It generates a hypertext link in the documentation to the specified class.
 @see Classname#memberfunctionName: This is used for classes, interfaces,
member functions and fields. It generates a hypertext link in the documentation to
the specified member function.
 @version text: This is used for classes and interfaces to indicate the version
information for the code.
Naming Methods
Methods should be named by using a full English description, using mixed case with first
letter of every non-initial word capitalized.
Examples
 openConnection()
 printAddressLabel()
 save()
 delete()

Naming Getters
Getters are the methods that return the value of a field. Prefix the word 'get' or ‘is’ to the
name of the field.
Examples:
 getLastName ()
 getAccountNumber()
 isPersistent()
 isAtEnd()
Naming Setters
Setters are the methods that modify the values of a field. You should prefix the word 'set
to the name of the field.

B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 11

 Software Testing

Examples:
 setLastName (String aName)
 setAccountNumber(int anAccountNumber)
 setReasonableValues (Vector newValues)
 setPersistent (boolean isPersistent)
 setAtEnd (boolean isAtEnd)
Naming Constructors
Constructors are the methods that perform the necessary initialization when an object is
first created. Constructors are always given the same name as their class. For example, a
constructor for the class Patient would be Patient ().
Examples:
 Customer()
 SavingsAccount()
Naming Fields (Fields/Properties)
Fields that is collections, such as arrays or vectors, should be given plural names to
indicate that they represent multiple values.
Examples
 lastName
 zipCode
 unitPrice
 orderItems
Naming Components/Widgets
Components/Widgets have to be named appropriately (instead of buttoni1, button2, raju,
etc.) so that, it will be easy to identify their purpose and type.
Examples:
 okButton
 customerList
 fileMenu
 newFileMenuItem
Naming Constants
In Java, constants are typically implemented as static final fields of classes. The
convention is to use full words, all in uppercase, with underscores between the words.
Examples:
 MINIMUM_BALANCE
 DEFAULT_START_DATE
B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 12
 Software Testing

Naming Local Variables

A local variable is an object or data item that is defined within the scope of a block, often
a method. The scope of a local variable is the block in which it is defined.
Naming Streams
When there is a single input and/or output stream being opened, used, and then closed
within a method, the common convention is to use in and out for the names of these
streams, respectively. For a stream used for both input and output, use the name inout. An
alternative to this naming convention is to use the names inputStream, outputStream, and
ioStream instead of in, out, and inout respectively.
Naming Loop Counters
Since the scope of the loop counters is limited, use counters such as i, j, k. Counters such
as counter l, counter2 are appropriate for member functions.
Naming Exception Objects
Use the letter e for generic exceptions.
Naming Parameters (Arguments)
Convention to be followed for parameters is same as for local variables. Use full
description of the value or object being passed, prefix the name with the letter 'p' to
indicate that it is an argument.
Examples:
 pCustomer
 pInventoryItem
Naming Classes, interfaces and packages
 Naming Classes: Use a full English descriptor starting with the first letter
capitalized using mixed case for the rest of the name.
Examples:
 Customer
 Employee
 Order
 OrderItem
 FileStream
 String
 Naming Interfaces: Use mixed case with the first letter of each word capitalized.
Examples:
 Runnable
 Contactable
 Prompter
 Naming Packages: Use full description of the package appropriate to the main
function. Put all classes that can be grouped together into their own packages.
Examples:
 package Forms;
 package Widgets;
B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 13
 Software Testing

3.6 Static Analysis using Tools

Though manual review is a good mechanism for static analysis, a number of tools are
available, particularly for analysis of the source code. These tools will make our lives
easy by pointing out a number of defects in the code such as:
 Whether the code is as per the coding standards/guidelines.
 Syntax mistakes
 Declaring a variable and not using it.
 Unreachable code (also called dead code). Code which will never be executed is
called unreachable code.
 Security vulnerabilities of the code (such as buffer overflow).
 Portability problems (if the code contains machine dependent or operating system
dependent features, then the code is not portable).
 Coding metrics such as
 Total number of lines.
 Number of commented lines to the number of uncommented lines in some
organizations the ratio should be 1:1).
 Code complexity (number of function points, number of function calls
etc.)
3.6.1 Tool for Readability Improvement/ Indenting
When you write lengthy programs, indenting the code increases the readability. The shell
command ‘indent’ provides the automatic indenting feature.
To indent a C program, say hello.c, the shell command is as follows:
$indent hello.c
The following options are available.
Option Description
-bad Blank lines after indentation
-bap Blank line after each function/procedure body
-bbb Blank line before boxed comments
-sob Remove unnecessary blank lines in the source code
-br Braces on if line
-nbbo Break after Boolean operator
-bbo Break before Boolean operator
-clin Case indentation
-cn Comment indentation
-nsc Do not star comments
In some UNIX systems, the equivalent command is C beautifier (cb). The command
format is:
$cb hello.c
B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 14
 Software Testing

3.6.2 Portability Testing Tool

The "lint" utility available on the Unix/Solaris system can be used to check the portability
of the code.
In addition to portability problems, lint also gives messages regarding "bad programming
style". The various messages given by lint are:
 Unused variables and functions.
 Assigning a 'long' variable to an 'int'.
 Variables which are used first and set later.
 Unreachable break statements.
 Function that returns a value which is never used.
 Type casting problems.
 Non-portable character use [for example, if c is a character variable, the code if
((c = getchar() < 0) is not portable).
 Unusual constructs (for example: *p++; does nothing).
 Control statements that never succeed [if x is an unsigned integer, if(x < 0) is
never a success].
The command format of lint is as follows:
$ lint hello.c
The output will display the potential portability problems. We will show the lint
output for very simple files. You can pass your C programs through the lint utility and
study the output messages to see what kind of good (or bad?) code you write.
Here is a small C program with an include directive and the main function in which a
variable is declared and printf function is called.
#include <stdio.h>
void main(void)
{
int i;
printf("Hello\n");
}
Let us pass this program through lint utility by giving the command:
# lint -n test.c
Output:
test.c (as included in test.c)
(4) Warning: variable unused in function: i in main
name declared but never used or defined
value type declared inconsistently
function returns value which is always ignored printf
B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 15
 Software Testing

Now, let us revise the program slightly:

void main(void)
{
printf ("Hello\n");
}

Let us pass this program through lint utility by giving the command:
# lint -n test.c
Output:
test.c (as included in test.c)
Warning: implicitly declared to return int: printf
function returns value which is always ignored printf

3.6.3 Symbolic Execution

Symbolic execution is also known as symbolic evaluation. In this method, the program is
executed with symbolic data. For instance, consider the following program segment:
int x;
int i1, i2 :
x = i1 + i2;

For i1 and i2 variables, instead of giving the actual values, symbolic values such as p and
q are given and the results are computed. In this case, the value of x should be p + q. This
type of testing is very useful in some specialized applications that involve lot of
mathematics. Tools are available that carry out symbolic execution as manual testing by
using this approach is very difficult.

Let us test a conditional statement as:

if
condition
then
statements

The condition is first assumed to be true and symbolic execution is done. Then the
condition is assumed to be false and then symbolic execution is done. This type of testing
is very useful for long logical expressions.
Symbolic execution has limitations--overflow cannot be detected. It is also not very
suitable for loops. Hence, only portions of the program can be checked and hence scope
of this type of testing is very limited.

B.L.D.E.A’S SSM POLYTECHNIC, CSE (S.R. INAMDAR) Page 16