Localization of Fault Based On Program Spectrum

International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 8 August 2013
ISSN: 2231-2803 http://www.ijcttjournal.org Page 2890

Localization of Fault Based on Program Spectrum

Dr. R.M.Chandrasekaran, N.suguna
Computer Science and Engineering,

Annamalai University
Annamalai nagar, India.

Computer Science and Engineering,

Annamalai University
Annamalai nagar, India.

Abstract
Fault localization is an expensive technique
in software testing. Fault localization means
finding the error or faults. In order to locate the
faults the developer identifies the statements
involved in failure and select suspicious
statements which contain fault. In this paper we
proposed a spectrum based fault localization. This
technique can improve the regression testing by
reducing the number of tests that needed to be run.
Spectrum-based fault localization uses various
program spectra to identify the behavioural
differences between old and new version of the
program under test. This comparison is useful for
finding the cause of failures or errors and presence
of difference in program spectra may indicate
those test cases for which the construction of
expected output .The developer can easily identify
whether the differences recorded in modified
version of code is due to regression faults or due to
changes made in the code.

Keywords: spectrum, program, fault
localization, testing
1. Introduction
Software fault localization is to find the fault that
causes software failure. The research estimates
most of the companies spend between 50% and
80% of software development effort on testing [1].
Regression testing is the process which includes
generation of a test suite , modification of the
source code, executing the test cases using
modified program, searching for deviation in the
output of finding the fault that cause software
failure. It is the most complex and difficult tasks
during the process of debugging [2]. Regression
testing tasks contains a significant percentage of
the costs of software testing. When modifications
are made in later stages of software development it
increases the cost also. A major difference
between regression testing and development
testing is that during regression testing a well
established test suite is available for reuse. A basic
technique for regression testing is retest-all
strategy i.e. retests all the test of test suite but it
may consume excessive time and resources which
may lead to increase in cost. On the other side,
regression test selection strategy reduces the time
needed to retest a modified program by selecting
some subset of the existing test suite. Therefore
the techniques that reduce the cost of regression
testing tasks are always valuable. Most of the
researches in regression testing concerns selective
retest techniques. Selective regression testing
techniques are described in [4]. But there are some
limitations with the conventional test selection
techniques. Regression testing is done to compare
the behaviour of the modified version to the
behaviour of its previous version. This comparison
is also useful in pinpointing the cause of failures or
errors [5]. The behaviour of the program can be
identified by characterizing the program spectrum.
The program spectra can be characterized in many
ways: path profiling, path spectra, node spectra,
edge spectra, branch spectra, complete path
spectrum, data dependence spectra, output
spectrum, execution trace spectrum, value spectra,
block spectra etc. [6,7]. The program spectra
provide an understanding to testing and
maintenance tasks. The difference in program

spectra may also indicate those test cases for
which the construction of expected output or
oracles or specifications is not needed. This may
also helpful for the developers to locate the faults
in the program [5].

This paper proposes a method for program
spectrum-based fault localization in regression
testing that identify the behavioural differences
between two versions of c#programs, finding the
faults, and identify those test cases that exercise
the dynamic behaviour of the modified version of
the program. Section 2 describes the different
existing fault localization techniques. Section 3
explains about Program spectra. Section 4 defines
SBFL. Section 5 describes the experimental
results. Section 6 defines conclusion.
2. Related work
Fault Localization is a complex and time
consuming process In order to improve the quality
of the programs errors must be removed at the
same time new errors were not found. There are
several techniques for fault localization. The first
technique was introduced by Mark Weiser named
as slicing [6]. A slice is an executable set of
statements which preserves the original behaviour
of the program with respect to a subset of variables
at a given program point [7]. Slicing algorithms
can be classified depending on whether they only
use statically available information (static slicing)
or compute those statements which influence the
value of a variable for a specific program input
(dynamic slice) [6]. In [7] an efficient dynamic
slicing algorithm is presented. It is mainly used for
debugging, program integration software
maintenance and reverse engineering.
Statistics based fault localization technique finds
the fault in the program by contrasting the
statistics of the evaluation results of individual
predicates between failed runs and successful runs
.It uses the short circuit evaluations to improve
predicate based statistical fault localization
techniques. Liblit et al propose a statistical
debugging algorithm (referred to as Liblit05)
identify bugs in the programs with instrumented
predicates at particular points [8]. Feedback
reports are generated by these instrumented
predicates. Predicates with a higher score should
be examined first to find bugs. Once a bug is
found and fixed, the feedback reports related to
that particular bug are removed. This process is
continued until other bugs and all the feedback
reports are removed or all the predicates are
examined.
Wong et al. [9] proposed a crosstab method
(referred to as Crosstab) to find the suspiciousness
of each executable statement in terms of its
likelihood of containing program bugs. It uses the
neural network to locate the bugs effectively. It
identifies the relationship between the statement
coverage information of a test case. It uses this
information for success or failure of a test case.
Zeller, et al. presents a program state-based
debugging technique, delta debugging, to reduce
the causes of failures to a small set of variables by
contrasting program states between executions of a
successful test and a failed test via their memory
graphs [10].

Gupta et al. [11] introduce the concept of failure
inducing chop as an extension to the cause
transition method to overcome this issue. First,
delta debugging is used to identify input and
output variables that are causes of failure.
Dynamic slices are then computed for these
variables, and the code at the intersection of the
forward slicing of the input variables and the
backward slicing of the output variables is
considered suspicious. run and Ernst [12] presents
a learning model using machine learning (e.g.,
Support Vector Machines) to differentiate faulty
and non-faulty programs using static analysis.
Build the program model using the program
properties (e.g., variables that are not initialized).
The classification step identifies feeding as input
the properties of a new program, and then the

properties are ranked according to the strength of
their association with faulty programs.

Program spectrum based technique identifies the
suspicious statement in a program responsible for
failure. It records the execution information to find
the success or failure of a statement. [3].
Spectrum-based fault localization strategy uses
different program spectra to identify the
behavioural differences between old and new
version of the program under test. This
comparison is also useful for finding the cause of
failures or errors and presence of difference in
program spectra may indicate those test cases for
which the construction of expected output or
oracle or specification is not needed. The proposed
approach can identify and localize the faults
effectively and also identify those test cases from
pre-existing test suite available for existing
program that exercise the changed behaviour of
the modified code. In this paper we studied the
spectrum based fault localization .We generate the
matrix for finding the behavioural difference on
two versions of program by test execution,
identification of type of fault and finding of faults,
identification of modification-traversing and fault
revealing test cases for Dot net programs.

3. Spectrum Based fault localization

The term program spectra arise from path profiling
in which distribution of the paths derived from run
of the program. A program spectrum finds the
programs run-time behaviour by recording the
execution information of a program such as
execution of conditional branches or execution of
intra-procedural paths or execution of def-use
pairs etc. Different program spectra have been
given in literature [3,4] used as a component to
find the quality of fault localization approach by
deriving its correlation with the programs
behaviour. A program spectrum is a collection of
data that provides a specific view of the dynamic
behaviour of software. It includes various spectra
like node spectra, edge spectra, edge pair spectra
and block pair spectra have been discussed. It
provides information about the parts of the
program that were executed during several test
cases during the execution of test cases data is
collected indicating the statements that are
executed. Various spectra used in this paper are:

Node spectra: It traces the set of single loop
intraprocedural nodes as program executes.

Edge spectra: Edge spectra traces the set of edges
with interprocedural multiple paths.

Edge-pair spectra: It traces the set of edge pair
with interprocedural multiple paths

Block spectra: It traces the set of blocks with
intraprocedural paths Let p be the original program
and p be the modified program. These programs
are implemented in c#

Program p

Using System;
1. Class fact {
2.int f=1; int n; int i;
3.if(i<n)
{
4.f=f*I; i++;
5.Console.writeln(f);
}
6.else if(i>n)
{
7.f=f+i
}
8.else
9.f=f-i
}

Program p

Using System;
1.Class fact{
2.Int f=1; int n; inti;
3.if(i<n)
{
4.f=f*I; i++;
}
6.else if(i>n)

{
7.f=f+i
8. n=n+2
9.if(n<8){
10. n=n+3
11.while(n%2==0){
12n++;
}
}
13.else
14.f=f-i
}

P and P are the two programs. P is the original
program. After making some changes in p the
resulted program is P Three different conditions
are given in both of the programs. The changes are
made in the program p when (i>n) In original
program 10 statements are there and after making
some changes new program is of 15 statements.

Fig 1: CFG of Program P.

Fig1 shows the CFG of program p. The graph
consists of 11 nodes. It is a directed graph in
which arrow shows the direction of flow of
control.Fig2 shows the CFG of program p. The
graph consists of 14 nodes. It is also a directed
graph in which nodes represent corresponding
statements and arrow shows the direction of flow
of control. Different nodes are attached with each
other through edge and edge pairs

Fig 2: CFG of Modified Program P
6
9
10
11
1
2
3
4
5
7
8
14
1
2
3
4
5
6
7
8
9
12
13
11

Table1:Computed Program Spectrum for
Program P

Table 2 : Computed Program Spectrum for
Program P

B1
B2

B3 B4

B5 B6

B7
Fig 3 : Block Diagram of Program P

B1
B2

B3 B4

B5
B6

B7
Fig 4 : Block Diagram of Program P
Fig 3 and 4 shows the block diagram of program p
and p. A block that ends in a decision has two
outgoing edges. Table 1 defines the different
spectra for program p. Table 2 defines the different
Te
st
id
Inpu
t
valu
es
Node
spectra
Edge
spectra
Edge-Pair
spectra
Te
st1
(3,2)

{1,2,3,7
,8,11}
[{1,2},{2,3}
,{3,7},{7,8}
,{8,11}]
[{1,2,3},{2,
3,7},{3,7,8}
,{7,8,11}]
Te
st
2
(4,8) {1,2,
3,4,5,6,
11}
[{1,2},{2,3}
,{3,4},{4,5}
,{5,6},
{6,11}]
[{1,2,3},{2,
3,4},{3,4,5}
,
{4,5,6},{5,6
,11}]
Te
st
3
(5,5
)
{1,2,3,7
,9,10,1
1}
[{1,2},{2,3}
,{3,7},{7,9}
,{9,10},
{10,11}]
[{1,2,3},{2,
3,7},{3,7,9}
,
{7,9,10},{9,
10,11}]
Te
st4
(8,3) {1,2,3,7
,8,9,14}
[{1,2},{2,3}
,{3,7},{7,8}
,{8,9},{9,14
}]
[{1,2,3},{2,
3,7},{3,7,8}
,
{7,8,9},{8,9
,14}]
Te
st
id
Inpu
t
valu
es
Node
spectra
Edge
spectra
Edge-Pair
spectra
est
1
(3,2)

{1,2,3,7
,8,11}
[{1,2},{2,3}
,{3,7},{7,8}
,{8,11}
[{1,2,3},{2,
3,7},{3,7,8}
,{7,8,11}]
Te
st
2
(4,8) {1,2,
3,4,5,6,
11}
[{1,2},{2,3}
,{3,4},{4,5}
,{5,6},
{6,11}]
[{1,2,3},{2,
3,4},{3,4,5},
{4,5,6},{5,6,
11}]
Te
st
3
(5,5
)
{1,2,3,7
,9,10
,11}
[{1,2},{2,3}
,{3,7},{7,9}
,{9,10},
{10,11}]
[{1,2,3},{3,
7,9},
{7,9,10},
{9,10,11}]
Te
st4
(8,3) {1,2,3,7
,8,11}
[{1,2},{2,3}
,{3,7},{7,8}
,{8,11}]
[{1,2,3},{2,
3,7},{3,7,8},
{7,8,11}]
If i<n
While(f<5)
F=f*I,i++
else if (i>n)
else f=f-1
while(f%2==0)
i=i+2,f=f+4
f++
return(f)
Int f=1, n,i=1
Int f=1,intn,i
If i<n
While(f<5)
f=f*I
;i++
else if (i>n)
f=f-i f=f+i
return {f)

spectra for program p. There are different test
cases are run to provide different spectra. In
program p three conditions are given , but some
changes are made in program p resulting in PIn
program p three conditions are given in the code
but there are some modifications are done in
program p in condition (2) i.e when (i>n) resulting
in program p. For test id test1, test2, test3 node
spectra, edge spectra, edge-pair spectra are same
for both program p and p but there is a difference
in block spectrum for testid (4,8).

Test id Block spectra
(3,2) B1,B2,B4,B5,B7
(4,8) B1,B2,B3,B7
(5,5) B1,B2,B6,B7
(8,3) B1,B2,B4,B5,B7

Table 3 : Block Spectra of Program P

Test id Block spectra
(3,2) B1,B2,B4,B5,B7
(4,8) B1,B2,B3,B11
(5,5) B1,B2,B4,B6,B7
(8,3) B1,B2,B4,B5,B7

Table 4 : Block Spectra of Program P
Block spectra are defined for both programs p and
p. A block is a section of code which is grouped
together. Block consists of one or more declaration
and statements in program p and p.Table3 and
table 4 shows the block spectra for program p and
p. Assume that a program spectrum of program p
is Ps (P) and modified program is Ps (p). Ps (P)
and Ps (p). are equivalent only if sequence of
conditional branches are same in both the
programs if Ps (P) and Ps (p) are not equal it
shows that there is behavioural difference between
the two programs. The behavioural difference
between the two programs p and p are arranged
for spectrum based fault localization. Four spectra
are calculated for program p i.e. Node spectra
(NS), Edge spectra (ES), Edge Pair spectra (EPS),
Block spectra (BS).
NS ES EPS BS
T1: (3,2) 1 1 1 1
T2: (4,8) 1 1 1 0
T3: (5,5) 1 1 1 0
T4: (8,3) 1 1 1 1
T
V
S
mat
Fig 5 : Vector T
v
ad matrix S
mat

We use a matrix S
mat
and Tv to track the computed
result of each spectra. If the spectra p is
equivalent to the corresponding spectra p for a
given test case, then it shows 1 otherwise 0. If the
corresponding value of NS, ES, EPS, BS is 1 then
it indicates that there is no behavioural difference
between old and modified program. This modified
code is given to the developer to find whether the
change in behaviour of new program is due to
regression fault or change in code. If regression
fault is there then the faults are removed without
execution of testcases and no need to write oracles
or specification for them. If behaviour of program
is changed due to modifications in the code then
new test cases are generated.
4. Experiments:
We developed a program in C# and find the
program spectra on existing program P and
modified program P' by test execution. Each
program spectrum to the corresponding test cases
are stored in the form of values 1 or 0 in a matrix
we used seven C#programs as subjects in the
experiment. First program is simple program to
sort the numbers and other five programs with
faulty versions and a set of test cases. The faulty
version of a program can be created by manually
seeding the faults in the existing version of
program to make it differs from the existing
program by one to seven lines of code.

Table 5 shows the subject program name,
description, lines of code, number of faulty version
created, number of test cases in input test suite I
that is available for existing program P, and
number of test cases in input test suite I that
reflects the spectra differences on modified
version of program P'. The creation of faulty
version of program simulates the scenario of
introducing regression faults into the subject
programs during modifications.

Program Loc Faulty
version
Tests Number of
tests that
reflects
spectra
differences
1.Sorting.cs 15 1 12 2
2.Stack.cs 32 3 32 8
3.Matrix.cs 40 8 30 7
4.Biary tree.cs 70 24 42 11
5.Linked
list.cs
73 15 35 9
6.Inheritece.cs 20 4 20 5
7.Queue.cs 35 8 40 13

Table 5: Experimental results
From results, we identified that those test cases
that reflect the behavioural differences between
two versions of program by means of by
comparing selected program spectra, statically.
These test cases are modification-traversing test
cases and provide better fault detection capability
compared to the rest of the test cases present in the
existing test suite as they exercised the changed
behaviour of the modified version of the program.

5. Conclusion and future work
In this paper we develop an efficient fault
localization technique based on spectrum based
fault localization and proposed an approach for
regression testing to identify four issues: The first
one is selection of suitable program spectra for
fault localization in regression testing, second a
process to identify the behavioural differences on
two versions of program by test execution,
identification of type of fault and finding of faults,
identification of modification-traversing and fault
revealing test cases.
We used different spectra such as node spectra,
edge spectra, edge pair spectra, block spectra for
finding the fault in the program. These program
spectra have been utilized in the proposed fault
localization approach for regression testing. In
previous work fault localization in done for c, c++
and java programs. In the proposed work fault
localization is applied for Dot net programs. The
main focus of spectrum based technique is to
reduce the number of tests that need to be run, by
revealing faults that does not change in output and
also identify the part of code which cause
deviation. The proposed approach effectively
identifies the part of the code which consists of
changes or regression faults. If regression fault is
present then these faults are removed without
execution of test cases and there is no need to
write or check oracles or specifications for them. If
behaviour of the program is changed due to
changes made in the modified version of code then
new test cases are need to be generated. This
approach can effectively localize the faults in
terms of branch, path, and execution spectra
deviations.

References
1. James A. Jones, Mary J ean Harrold, John
Stasko, Visualization of Test Information to
Assist Fault Localization ,College of Computing
Georgia Institute of Technology Atlanta, GA,
ACM Journal 2001.

2. Anita Devi Spectrum Based Fault Localization
International Journal of Computer Trends and
Technology (IJCTT) volume 4 Issue6-June
2013.ISSN: 2231-2803 http://www.ijcttjournal.org
Page 1698.

3.Shailesh Tiwari, K.K Mishra and A.K. Misra,
Regression Testing: A Spectrum-based
Approach, International Journal of Computer

Applications (0975 8887) Volume 55 No.18,
October 2012.

4.Gregg G. Rothermel and M.J. Harrold,
Analyzing Regression Test Selection
Techniques, IEEE Trans. Software Eng., vol. 22,
no. 8, pp. 29-551, Aug. 1996.

5.Mary J ean Harrold, Gregg Rothermel, Rui Wu,
and Liu Yi. 1998. An empirical investigation of
program spectra. SIGPLAN Notes 33, 7 (July
1998), 83-90.
6.M.Weiser , Program slicing,.IEEE
transactions on software engineering ,SE-
10(4):352-357, 1984.

7.J.W. Laski and B. Korel, A Data Flow Oriented
Program Testing Strategy, IEEE Trans. Software
Eng., vol. 9, no. 3, pp. 347-354, May1983.

8. B. Liblit, M. Naik, A. X. Zheng, A. Aiken, and
M. I. Jordan, Scalable Statistical Bug Isolation,
in Proceedings of the 2005 ACM SIGPLAN
Conference on Programming Language Design
and Implementation, pp. 15-26, Chicago, Illinois,
USA, June, 2005.

9. W. E. Wong, T. Wei, Y. Qi, and L. Zhao, A
Crosstab-based Statistical Method for Effective
Fault Localization, in Proceedings of the 1st
International Conference on Software Testing,
Verification and Validation, pp. 42-51,
Lillehammer, Norway, April 2008.

10. Zeller, Isolating Cause-Effect Chains from
Computer Programs, in Proceedings of the10th
ACM SIGSOFT Symposium on Foundations of
Software Engineering, pp. 1-10, Charleston, South
Carolina, USA, November 2002.

11. N. Gupta, H. He, X. Zhang, and R. Gupta,
Locating Faulty Code Using Failure-Inducing
Chops, in Proceedings of the 20th IEEE/ACM
International Conference on Automated Software
Engineering, pp. 263-272, Long Beach, California,
USA, November 2005.

12. Y. Brun and M. D. Ernst, Finding Latent
Code Errors via Machine Learning over Program
Executions, in Proceedings of the 26th
International Conference on Software Engineering,
pp. 480- 490, Edinburgh, UK, May 2004.

13.Tiwari, S.; Mishra, K.K.; Kumar, A.; Misra,
A.K.; , "Spectrum- Based Fault Localization in
Regression Testing," Information Technology:
New Generations (ITNG), 2011 Eighth
International Conference on , vol., no., pp.191-
195, 11-13 April 2011 doi:
10.1109/ITNG.2011.40.

14.Anjaneyulu Pasala and et al., Selection of
Regression Test Suite to Validate Software
Applications upon Deployment of Upgrades,
IEEE 19th Australian Conference on Software
Engineering, November, 2008.

15.M. J. Harrold, G. Rothermel, K. Sayre, R. Wu,
and L. Yi, An Empirical Investigation of the
Relationship between Spectra Differences and
Regression Faults, Journal of Software Testing,
Verification and Reliability, 10(3):171-194,
September 2000.

16.Yoo, S., & Harman, M. (2010). Regression
testing minimization, selection and prioritization:
A survey. Software Testing, Verification and
Reliability. doi:10.1002/stvr.430.
17.T. Ball and J.R. Larus. Efficient Path Profiling
in Proc. Of Micro 96, Pages 46-57, Dec 1996.

18.Xie, T., Notkin, D.: Checking inside the black
box: Regression testing by comparing value
spectra. IEEE Transactions on Software
Engineering 31(10), 869883 (2005)

19. J. F. Bowring, J. M. Rehg, and M. J. Harrold.
Active learning for automatic classification of
software behavior. InProceedings of the 2004
ACM SIGSOFT International Symposium on
Software Testing and Analysis, pages 195205,
New York, 2004. ACM Press.

20.Zhenyu Zhang, W.K. Chan, T.H. Tse, Y.T. Yu,
Peifeng Hu, Non-parametric statistical fault
localization, Journal of Systems and Software,
Volume 84, Issue 6, June 2011, Pages 885-905,
ISSN 0164-1212, 10.1016/j.jss.2010.12.048.


21.Sample programs are taken for experiments
from Software Infrastructures Repository (SIR)
http://sir.unl.edu/content/sir.php.

22.A.Orso and T.Xie. BERT: Behavioral
Regression Testing. In Proc. WODA, pages 36
42, 2008.

Localization of Fault Based On Program Spectrum

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Localization of Fault Based On Program Spectrum

Загружено:

Авторское право:

Доступные форматы

International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 8 August 2013

ISSN: 2231-2803 http://www.ijcttjournal.org Page 2890

Вам также может понравиться