\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={A Fitness Function for Search-based Testing of Java Classes, which is based on the States Reached by the Object under Test},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2016-01-15 (revised: 15 January 2016)}
\def\TheID{\makeatother }
\def\TheDate{2016-01-15}
\title{A Fitness Function for Search-based Testing of Java Classes, which is based on the States Reached by the Object under Test}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Ina  Papadhopulli}

             \author[2]{Elinda  Mece}

             \affil[1]{  Polytechnic University of Tirana}

\renewcommand\Authands{ and }

\date{\small \em Received: 11 December 2015 Accepted: 3 January 2016 Published: 15 January 2016}

\maketitle


\begin{abstract}
        


Genetic Algorithms are among the most efficient search-based techniques to automatically generate unit test cases today. The search is guided by a fitness function which evaluates how close an individual is to satisfy a given coverage goal. There exists several coverage criteria but the default criterion today is branch coverage. Nevertheless achieving high or full branch coverage does not imply that the generated test suite has good quality. In object oriented programs the state of the object affects its behavior. Thereupon, test cases that put the object under test, in new states are of interest in the testing context. In this article we propose a new fitness function which takes into consideration three factors for evaluation: the approach level, the branch distance and the new states reached by a test case. The coverage targets are still the branches, but during the search, the state of the object under test evolves with the scope to produce individuals that discover interesting features of the class and as a consequence can discover errors. We implemented this fitness function in the eToc tool. In our experiments the usage of the proposed fitness function towards the original fitness function results in a relative increase of 15.6% in the achieved average mutation score with the cost of a relative increase of 12.6% in the average test suite size.

\end{abstract}


\keywords{structural testing, test case generation, search based software testing, fitness function, object state, coverage criteria, mutation score.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{I. INTRODUCTION}]{I. INTRODUCTION}\par
ue to the fact that the influence of software in all areas has grown rapidly in the past 40 years, the software has become very complex and also its reliability is fundamental. All the software development phases have been adapted to produce these complex software systems, but especially the testing phase is of critical importance and testing thoroughly today's software systems is still a challenge. According to a study \hyperref[b0]{[1]} conducted by the National Institute of Standard \& Technology, approximately 80\% of the development cost is spent on identifying and correcting defects. It is a well-known fact that it is a lot more expensive to correct defects that are detected during later system operation. Considering past experiences, inadequate and ineffective testing can result in social D problems and human/financial losses. In order to improve the testing infrastructure, several efforts have been made to automate this process.\par
In the unit testing level, there are three approaches towards automation: random testing, static analysis (Symbolic Execution \hyperref[b1]{[3]}) and metaheuristic search. A considerable number of tools have been developed based on these approaches; eg. RANDOOP \hyperref[b2]{[4]}, EvoSuite \hyperref[b3]{[5]}, AgitarOne \hyperref[b4]{[6]}. Nevertheless, the effectiveness of these tools is still not completely proved, because the results obtained from the experiments depend on the subjects under test. Usually, a coverage criteria is used to evaluate these tools, but achieving a high degree of code coverage does not imply that a test is actually effective at detecting faults \hyperref[b5]{[7]}. According to \hyperref[b6]{[8]}, today there is no tool to find more than 40.6\% of faults.\par
This article is focused on structural testing at the unit level of Java programs using Search-Based Software Testing (SBST) \hyperref[b7]{[9]}. According to \hyperref[b8]{[10]}, SBST has been used to automate the testing process in several areas including the coverage of specific program structures, as part of a structural, or white-box testing strategy. Every unit (class) of the software must be tested before proceeding to the other stages of the development cycle. SBST is a branch of Search Based Software Engineering (SBSE). SBSE is an engineering approach in which optimal or near optimal solutions are sought in a search space of candidate solutions. The search is guided by a fitness function that distinguishes between better and worse solutions. SBSE is an optimization approach and it is suitable for software testing since test case generation is often seen as an optimization or search problem. Since SBST techniques are heuristic by nature, they must be empirically investigated in terms of how costly and effective they are at reaching their test objectives and whether they scale up to realistic development artifacts. However, approaches to empirically study SBST techniques have shown wide variation in the literature. There exist several search-based optimization methods used for test automation; e.g. genetic algorithms, hill climbing, ant colony optimization and simulated annealing, etc, but Genetic algorithms (GAs) are among the most frequently applied in test data generation.\par
GAs have several components which need to be defined in order for the GA to be implemented.\par
According to \hyperref[b8]{[10]}, the component that affects mostly the results obtained from the search is the fitness function. The fitness function is a mathematical representation of the coverage goal the search should achieve. There are different coverage goals each of them aims at covering certain parts of the unit under test. These different coverage criteria verify the quality of a test suite. The gold criterion is strong mutation, but today this criterion it is mainly used by the research community for evaluation of proposed techniques. The most used criterion is branch coverage \hyperref[b9]{[11]}. However achieving high branch coverage (even 100\%), for some classes is not sufficient.\par
In object oriented programs the state of the object is a factor that affects the execution of a method. This is why the state of the object of the Class Under Test (CUT), should evolve during the search in order to discover hidden features of the class \hyperref[b10]{[12]}. A test case that puts the object in one or several new states is of interest in the testing context. The scope of this paper is to propose and evaluate a new fitness function, which rewards the test cases according to branch coverage and also according to the new states the object has taken during the execution of the test.\par
The rest of this paper is organized as follows: In the second section we explain in what unit testing of java programs consists and in the third section we present an overview of GAs. The fourth section is focused on branch coverage and the fifth section presents the proposed fitness function. The implementation of the proposed fitness function is described in section six. The seventh section gives details of the experimental setup and in the eighth section the results achieved are presented and discussed. We conclude finally with the conclusions we have come preparing and accomplishing this study. 
\section[{II.}]{II.} 
\section[{UNIT TESTING FOR OBJECT ORIENTED SOFTWARE}]{UNIT TESTING FOR OBJECT ORIENTED SOFTWARE}\par
Software testing at the unit level (Java classes) consists of three steps:\par
1) The design of test cases 2) The execution of these test cases\par
3) The determination of whether the output produced is correct or not. The second step is performed fully automatically using frameworks like JUnit  {\ref [2]}. Automatically generating the test oracle is still a challenge and there exists few research publications regarding this topic \hyperref[b11]{[13]}, therefore the third step is almost completely performed manually by the testers. Regarding the first step, there exist a lot of research effort for the generation of test cases automatically. Due to the complexity and the diversity of the programs under test this is still an open research topic. Moreover test cases in object oriented unit testing are not just a sequence of input values like in procedural languages. According to \hyperref[b12]{[14]}, a unit test of a Java class must accomplish the following four tasks:  The space of potential solutions is searched in order to find the best possible solution. This process is started with a set of individuals (genotypes) which are generated randomly from the whole population space (phenotype space). New solutions are created by using the crossover and mutation operators. The replacement mechanism selects the individuals which will be removed so that the population size does not exceed a prescribed limit. The basis of selection is the fitness function which assigns a quality measure to each individual. According to the fitness function, the parent selection mechanism evaluates the best candidates to be parents in order to produce better individuals in the next generation. It is the fitness function which affects the search towards satisfying a given coverage criteria. Usually the fitness function provides guidance which leads to the satisfaction of the coverage criterion. For each individual the fitness is computed according to the mathematical formula which represents how close is a candidate to satisfy a coverage goal, e.g. covering a given branch in the unit under test. GAs are stochastic search methods that could in principle run for ever. The termination criterion is usually a search budget parameter which is defined at the beginning of the search and represents the maximum amount of time available for that particular search. 
\section[{IV. COVERAGE CRITERIA a) Types of Coverage Criteria}]{IV. COVERAGE CRITERIA a) Types of Coverage Criteria}\par
Automatic unit testing is guided by a structural coverage criterion. There exist many coverage criteria in literature, each of them aims at covering different components of a CUT. Nevertheless, not all the criteria have the same strength and can be fulfilled practically. Furthermore some criteria are subsumed by other criteria. Below is a list of coverage criteria for structural testing of Java programs.  \hyperref[b13]{[15]}. This criterion is difficult to apply and computationally expensive and it is practically only used for predicting suite quality by researchers. Another option to achieve high quality test cases with search based technique is to use a combination of multiple criteria. \hyperref[b14]{[16]} performed an experiment to evaluate the effects of using multiple criteria and concluded that: ? Given enough time the combination of all criteria achieves higher mutation score than each criterion separately (except Weak Mutation). ? Using all the criteria increases the test suite size by more than 50\% that the average test suite size of each constituent criterion used separately. ? The next best criterion (after Weak Mutation) to achieve high mutation scores is branch coverage.\par
The usage of multiple criteria increases the overall coverage and mutation score with the cost of a considerable increase in test suite length, so the usage of the combination in practice will be not feasible, because managing large test suites is difficult. A balance between mutation score and average test suite size is achieved with branch coverage criterion. 
\section[{b) Branch Coverage}]{b) Branch Coverage}\par
The most used criterion is branch coverage, but even though it is an established default criterion in the literature, it may produce weak test sets (mutation score less than 30\% \hyperref[b15]{[17]}). For example consider the Stack implementation in Figure  {\ref 1}. public 
\section[{Analyzing class Stack we notice the following errors :}]{Analyzing class Stack we notice the following errors :}\par
? If method pop is called first and then is called method push, an uncaught exception is thrown (field size before calling push is -1). ? If method pop is called two times consequently an uncaught exception is thrown (field size before calling pop is -1). ? If method push is called four times consequently and then is called method pop an uncaught exception is thrown (field size before calling pop is 4).\par
? It is obvious that branch coverage is not sufficient for class Stack! Is there any possibility to improve the fitness function for branch coverage in order to obtain a test suite with higher quality? Both of the methods are covered by the test generated, but it is evident that the state of the object (the value of field size) before calling them affects the results of the tests. The same method called on different states of the object behaves differently. This is why, a possibility to improve the suite's ability to detect errors, is to evolve the state of the object during the search in order to put the object in new states that probably can discover interesting behaviors of the CUT. Since the search is guided by the fitness function, then this function should also consider the states reached by a test before evaluating it. 
\section[{V. THE PROPOSED FITNESS FUNCTION}]{V. THE PROPOSED FITNESS FUNCTION}\par
Fitness functions are a fundamental part of any search algorithm. They provide the means to evaluate individuals, thus allowing a search to move towards better individuals in the hope of finding a solution \hyperref[b16]{[18]}. The approach considered here is to minimize the fitness function during the search. The fitness function proposed in this paper rewards the individuals based on how close they are at covering a target (branch) and the states they put the object under test. This function is a mathematical equation depending on the:? Approach level ? Branch Distance ? New states achieved a) Approach Level\par
For each target, the approach level show how many of the branch's control dependent nodes were not executed by a particular input \hyperref[b18]{[20]}. The fewer control dependent nodes executed, the "further away" an input is from executing the branch in control flow terms. The approach level is the most used factor in the fitness function for structural criteria, but the fitness landscape contain plateaus because the search is unaware of how close a test case was to traversing the desired edge of a critical branching node. 
\section[{b) Branch Distance}]{b) Branch Distance}\par
The branch distance is computed using the condition of the decision statement at which the flow of control diverted away from the current "target" branch. For every operator the branch distance is calculated using the formulas introduced by Tracey \hyperref[b17]{[19]}.\par
The approach level is more important that the branch distance and as a consequence the branch distance should be normalized at the fitness function formula. This distance will be normalized at a value between 0.0 and 1.0. Value 0.0 means "true"; the desired branch has been reached. Values close to 1.0 means that the condition is far from being fulfilled. Intermediate values guide slightly the search towards the accomplishment of the condition (in order to remove plateaus in the fitness landscape). The formula for branch distance in our proposed fitness function is the formula introduced by Arcuri \hyperref[b19]{[21]}. 
\section[{????(????????????????????) = ???? ???? + ??}]{????(????????????????????) = ???? ???? + ??}\par
BD is the branch distance before normalization and ?? is 1. 
\section[{c) New States Achieved (NSA)}]{c) New States Achieved (NSA)}\par
With the term state in this paper we refer to: Definition 1. State: The set of the values of all the fields in the CUT before calling a method + the method called.\par
For example, for the class Stack the two states:\par
? field size = 0 and filed st = !null, before calling method push ? field size = 0 and filed st = !null, before calling method pop are considered two different states and both of them are interesting in the testing context. The total number of states in the CUT is computed as a product of all the possible combinations Even though class Stack is very simple, and the branch coverage obtained is 100\%, the mutation score is relatively low (29\%). We added an assertion in the test (line 7) and used the JUnit framework to run it in Eclipse. The test passed. The tester may assume the class is correct with 100\% branch coverage and a passing test.\par
Is branch coverage sufficient for this class? of the class fields (declared non final) after abstraction (explained in the next section), with the number of public methods.\par
The approach level is more important that the number of new states achieved and as a consequence this factor should be normalized at the fitness function formula. The normalization formula is:?????? = ????????????\textunderscore ?????????? -????????????\textunderscore ?????? ????????????\textunderscore ??????????\par
The greater the number of the new states achieved by a test case the smaller this factor in the overall fitness.???????????? = ???????????????\textunderscore ?????????? + ???? ????+1 + ???????????? \textunderscore ?????????? -???????????? \textunderscore ?????? ???????????? \textunderscore ?????????? d) Abstract States\par
If we use the real values of the fields, the number of states will be infinite. Moreover, not all the states are of equal relevance during testing. For example, from the testing prospective, calling method pop() of the class Stack with field size = 1, is the same as calling method pop with filed size = 2. On the other hand calling method pop() with filed size = 0 in not the same, since this state reveals an interesting behavior of the object under test. Therefore, we use abstractions over the values of the fields rather than the concrete values themselves. We use a state abstraction function provided by Dallmeier at al. \hyperref[b28]{[34]}. The abstraction is performed based on the three rules below:\par
? If the type of the field is concrete (int, double, long etc), the value will be translated in three abstract values: x i < 0, x i = 0 and x i > 0.\par
? If the type of the field is an object, the value will be translated in two abstract values: x i = null dhe x i null ? If the type of the field is Boolean, there is no need to do translation, since there are only two values.\par
For example the combinations of the field values of class Stack, after abstraction are those listed in Table \hyperref[tab_3]{1}.  
\section[{IMPLEMENTATION OF THE PROPOSED FITNESS FUNCTION}]{IMPLEMENTATION OF THE PROPOSED FITNESS FUNCTION}\par
The proposed fitness function was implemented in the eToc \hyperref[b20]{[22]} tool. eToc is a simple search based tool for unit testing of Java programs. Is uses GA and branch coverage criterion. This tool has been mentioned in many research works and has been used as the basis for the design of other tools. eToc is appropriate for the scope used in this work. In the high level architecture of this tool \hyperref[b20]{[22]}, the Branch Instrumentor module and the Test Case Generator module need to be differently implemented for the search to be guided by the proposed fitness function. The new implementation of these modules is described below. 
\section[{a) The Intrumentor}]{a) The Intrumentor}\par
The function of the instrumentor module is to transform the source code of the CUT in order to provide information about the executed branches, the branch distance and the states achieved during execution. The new statements added during instrumentation must not change the behavior of the CUT. In order to obtain information for the states reached by the object under test, for each of the attributes (except those declared final) of the CUT, a get method will be added. A static analysis can be used to provide information about the mutators and inspectors methods of a class \hyperref[b21]{[23]}[24], but in this case a static whole-program analysis is required, which is very expensive for this context used. Since it is not the purpose here to obtain a behavioral model of the CUT, the get methods are appropriate to be used as inspectors for obtaining the state of the object because these methods: ? Return the value of an attribute ? Do not take parameters ? Do not have any side effects in the execution of the program.\par
Based on the state definition given in section 5.C, the get methods should be called before the execution of each method of the CUT, so during instrumentation the statements calling the get methods are added before the existing statements of each method. The concrete values are translated in abstract values as described in section 5.D. Then the states reached by a test case are saved in a LinkedList and consequently during fitness evaluation the new states achieved by a test case can obtained. The instrumented version of the CUT is executed repeatedly with the scope to cover a specified target (branch of the CUT). The state lists resulting after each execution are compared with the state lists of the test cases that make up the population. The new states reached by an individual are used to compute part of its fitness.\par
This module is also responsible for the minimization of the generated test suite. Normally during minimization the tests that do not cover any target that is not covered by any other test are omitted from the test suite. Taking into consideration that a test case that reaches one or more new states is important in the testing context, before removing a test case because it does not cover any new target, it will be reconsidered regarding the states it puts the object under test in. The test cases which contain unreached states in their state lists, will be part of the final test suite. The proposed minimization has the advantage that it probably increases the number of tests in the generated test suite and as a consequence it also increases the length of the test suite. On the other side the usage of the proposed fitness function is expected to increase the capability of the test suite to detect errors. An experimental evaluation of the new fitness function is presented in the In this work we aim to answer the following research questions:\par
? RQ1: How does the usage of the proposed fitness function affect the branch coverage? ? RQ2: How does the usage of the proposed fitness function affect the mutation score of the suite? ? RQ3: How does the usage of the proposed fitness function affect the number of suite's test cases and their size?a) System Characteristics\par
For the experiments we used a desktop computer running Linux 32 bit Operating System, 1 GB of main memory and a Intel Core 2 Duo CPU E7400 2.8GHz x 2 Processor. 
\section[{b) Subject Selection}]{b) Subject Selection}\par
Selecting the classes under test is very important since this selection affects the results of the experiments. We chose 7 open source projects and selected randomly 23 classes from them. Also, the class Stack discussed throughout this paper was used as a subject for the experiments. To obtain comprehensive results, the evaluation must be done to real and not simple subjects. Also these subjects should not have any common characteristics which affect the obtained results. The characteristics of the 24 classes are listed in Table \hyperref[tab_7]{2}. The information about LOC (without comments and empty lines) and cyclomatic complexity is obtained using Metrics 1.3.6 [25], as a plugin in Eclipse. As can be noted from Table \hyperref[tab_7]{2}, the classes have very different characteristics and complexity.\par
Five of the projects were downloaded from SourceForge [26] which is today the greatest open source repository (more than 300,000 projects and two million of users). One project was downloaded from the Apache Software Foundation [27] which exists from 1999 and has more than 350 projects (including Apache HTTP Server). Class StringTokenizer was taken from the java.util package which is part of jdk 1.8.0. This package has been used by several studies for evaluation of automatic test case generation techniques. a) Parameters of GA Defining the parameters of GAs to obtain the optimal results is difficult and a lot of research effort is dedicated to this topic \hyperref[b23]{[28]} \hyperref[b24]{[29]}. Therefore we let the parameters of the GA to their default values \hyperref[b20]{[22]}. The values of three of the most relevant parameters are listed in Table  {\ref 3}. Regarding the search budget, it was determined depending on the experiment and will be shown next for each experiment. To overcome the randomness of the genetic algorithms each experiment was repeated 5 times.\par
The results of the experiments (average of all runs) are presented in Table  {\ref 4}. The branch coverage was measured with EclEmma. For both functions the average branch coverage is greater when the search budget is 10 min. This result was expected since the individuals improve during the search and more time results in better solutions.\par
In order to do the best comparison of the approaches we focus on the case with search budget of 10 min in this section, since for the scope of the experiment, it is not appropriate to compare results affected by the limited search time.\par
The difference between the average branch coverage is inconsiderable (0.4\%) when a search budget of 10 min is used. This difference may be due to the randomness of the results achieved by the search. Since the approach presented in this work does not change the targets to cover, the almost equal coverage was expected. For the class ExplorerFrame, there is an increase of 7\% in the coverage achieved by the proposed approach. Even though the targets are identical, the proposed function rewards the individuals that reach more new states and therefore the test cases after minimization may be different and more complex. So, this increase probably is the effect of indirect coverage.\par
Only in the case of class ArrayUtil there was a decrease of 1\% in the coverage achieved, with budget 2 min, but more likely it is due to the randomness of the search. For the class NewsFactory the search failed to produce results for both approaches. We changed the parameters of the GA, but even for a population of 20, or 30 individuals, no results were generated. It is not the scope of this work to investigate the reasons why this happened.\par
? RQ2: How does the usage of the proposed fitness function affect the mutation score of the suite?\par
Since mutation score is the measure used in the strongest criterion (Mutation Coverage), here we have used it to measure the quality of the generated test suite. Computing the mutation score for a test suite requires determining, for every mutant, whether the test suite succeeds or fails when run on the mutant. In the worst case each test must be run on each mutant. For each of the classes the mutants were generated using as a plugin in Eclipse the tool MuClipse v1.  {\ref 3 [30]}. Mu Clipse generates mutants using the traditional operators and the operators in the class level \hyperref[b25]{[31]}. The number of generated mutants for each class is given in generated, so that these cases can be used by MuClipse. Then, the generated tests were executed with JUnit against all the mutants and the presence of failures shows that the tests were able to kill the mutants.\par
The results of the mutation scores of each class for all the configurations are given in Table  {\ref 4}.\par
The mutation scores achieved by both of the fitness functions are far from the optimal value (100\%). Almost this range of mutation scores is also obtained from other studies \hyperref[b26]{[32]}. The main reasons of these low scores are: ? the targets to cover are the branches and not the mutants ? the presence of equivalent mutants (behave the same as the original program) which cannot be killed.\par
Nevertheless, despite the relatively low mutation scores, our interest is focused on the difference between the scores achieved by the original function against the proposed function.\par
For 6 classes (6/23 = 26\%) there is an improvement in the mutation score achieved when using a search budget of 10 min against a search budget of 2 min.\par
For the same reasons mentioned in the discussion of RQ1, to answer RQ2 we are focusing mainly at the results achieved with a search budget of 10 min. The average mutation score reached by the original function is 35.9\%, whereas the mutation score reached by the proposed function is 41.5\%, thus a difference of 5.6\%. The improvement is 5.6/35.9 = 15.6\%. For 15 classes out of 23 (15/23 = 65\%), there is an improvement in the mutation score achieved by the proposed function; for the remaining 8 classes (8/23 = 35\%), the scores achieved are identical. There is no class where using the proposed function results in a lower mutation score. Even though we are aware that the results depend fact that CUT chosen have different characteristics), the results obtained are very promising.\par
? RQ3: How does the usage of the proposed fitness function affect the number of suite's test cases and their size?\par
Automatically generated JUnit tests need to be manually checked in order to detect faults because automatic oracle generation is not possible today. This is the reason why not only the achieved coverage of the generated test suite is important, but the size of the test suite is of the same importance \hyperref[b27]{[33]}.\par
Here we refer to the size of a test suite as the number of statements after the minimization phase (without assertions).\par
Only the results achieved with a search budget of 10 min, are shown in Table  {\ref 4}, because in answering RQ3 we are interested in the number of tests generated and their size in the "worst case". The minimization phase does not depend on the search budget, so the results with search budget of 10 min, subsume the scenario with a search budget of 2 min. The LOC of the generated suite was obtained with the tool Metrics 1.3.6.\par
There is an increase of 314 -290 = 24 tests in the total number of test generated, or a relative increase of 24/290 = 8.2\%. This increase is acceptable, although the number of tests in the test suite is not relevant in respect to the size of the test suite, because having many short size tests is not a problem for the tester who is detecting faults.\par
Regarding the size of the test suite, we can see from the results in Table  {\ref 4}, that using the proposed fitness function results in an average test suite size of 33.9 (781/23) statements. The relative increase is (33.9 -30.1) / 30.1 = 12.6\%. For 8 of the classes (34\%), there is no change in the average test suite size. Regarding classes ExponentialFunction and GAAlgorithm (8.7\% of the classes), there is a decrease in the average test suite size, although there is no decrease either in branch coverage or mutation score. These results are explained with the appearance of indirect coverage \hyperref[b29]{[36]}.\par
ArrayUtil is the class with the greatest test suite size because of the large number of branches (167). The average increase in test suite size with the usage of the proposed function is the consequence of two reasons: ? During the minimization phase the test cases that do not cover any target, but put the object under test in new states, are added in the minimized test suite (as explained in Section 6)\par
? Two different fitness functions probably will generate different test suites with different number of statements (not necessarily a larger number). 
\section[{IX. CONCLUSIONS}]{IX. CONCLUSIONS}\par
This paper concerns the fitness function used to guide the search during automatic unit test generation of Java classes. The branch coverage criterion is easy to implement but can produce weak test sets. Test cases that put the object under test in new states discover hidden behaviors and consequently are relevant in the testing context. Targeting all the states during the search is impossible due to the fact that some of them are infeasible. In this article we presented a new fitness function that takes into consideration the states reached during the execution of a test case. The implementation of this fitness function is very simple since the targets to cover remain the branches, but the state evolve during the search and the minimization phase the tests that reach one or more new states are not removed even though these tests does not reach any uncovered branches. The usage of the proposed fitness function does not decrease the branch coverage and results in a relative increase of 15.6\% in the achieved average mutation score with the cost of a relative increase of 12.6\% in the average test suite size. The results are promising but since the subjects under test are very different further evaluation of the proposed approach needs to be performed.\begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}?}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-3.png}
\caption{\label{fig_1}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.7106306306306306\textwidth}P{0.13936936936936936\textwidth}}
\tabcellsep Year 2016\\
\tabcellsep 7\\
\tabcellsep Volume XVI Issue II Version I\\
class Stack \{\tabcellsep ( )\\
private int size = 0; private int st [] = new int [4]; void push (int x)\{ if (size < st.length) st[size++] = x; \} int pop ()\{ return st[size--]; \} The class Stack is very simple (8 LOC, 2 attributes, 2 methods). Suppose the test suite generated \} is the test suite given in Figure 2. 1. @Test 2. public void test0() \{ 3. Stack s0 =new Stack();\tabcellsep Global Journal of Computer Science and Technology\\
4. s0.push(1);\tabcellsep \\
5. s0.push(0);\tabcellsep \\
6. int int0 = s.pop();\tabcellsep \\
7. assertEquals(0, int0);\tabcellsep \\
8. s.push(0);\tabcellsep \\
9. s.push(0);\tabcellsep \end{longtable} \par
  {\small\itshape [Note: C © 2016 Global Journals Inc. (US) Figure1 : Example Stack implementation 10. s.push((-1916)); 11. s.push((-1916)); 12. \} Figure 2 :]} 
\caption{\label{tab_2}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.371875\textwidth}P{0.23020833333333332\textwidth}P{0.24791666666666667\textwidth}}
\tabcellsep size\tabcellsep st\\
state1\tabcellsep = 0\tabcellsep null\\
state2\tabcellsep > 0\tabcellsep null\\
state3\tabcellsep < 0\tabcellsep null\\
VI.\tabcellsep \tabcellsep \end{longtable} \par
 
\caption{\label{tab_3}Table 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{II} \par 
\begin{longtable}{P{0.06267605633802817\textwidth}P{0.20140845070422536\textwidth}P{0.060563380281690136\textwidth}P{0.055633802816901404\textwidth}P{0.07394366197183098\textwidth}P{0.04295774647887324\textwidth}P{0.048591549295774646\textwidth}P{0.08450704225352113\textwidth}P{0.15492957746478875\textwidth}P{0.0647887323943662\textwidth}}
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep Year 2016\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep 11\\
Project\tabcellsep Class\tabcellsep LOC\tabcellsep Branch\tabcellsep \multicolumn{2}{l}{Mutants next section. Non-}\tabcellsep Public\tabcellsep Cyclomatic\tabcellsep URL\tabcellsep Volume XVI Issue II Version I\\
\tabcellsep \tabcellsep \tabcellsep es\tabcellsep \tabcellsep final Fields\tabcellsep Methods\tabcellsep Complexity\tabcellsep e projektit\tabcellsep ( )\\
Comm ons CLI Math4 J jdk Geneti c Algorit h i Object Explor Newz Grabb er\tabcellsep Staku Option TypeHandler AlreadySelectedExcepti OptionGroup Rational ExponentialFunction ArrayUtil PolyFunction Complex StringTokenizer GAAlgorithm Genome Population ExplorerFrame ObjectViewManager DirectoryDialog StringSorter BatchJob NewsFactory SongInfo\tabcellsep 12 155 124 26 86 61 40 320 245 102 313 65 14 62 158 114 177 63 28 121 55\tabcellsep 4 131 28 4 21 36 11 167 100 24 78 14 9 13 26 41 47 12 11 45 12\tabcellsep 22 140 28 1 19 161 31 1769 827 682 434 6 21 44 74 41 155 47 29 88 59\tabcellsep 2 9 0 2 2 2 1 0 2 2 7 6 3 4 8 8 16 1 8 4 3\tabcellsep 2 42 9 2 8 19 9 36 12 20 6 8 4 11 9 17 13 4 10 7 4\tabcellsep 1.5 1.52 2.66 1 1.875 1.526 1 3.48 3.63 1.091 3.12 2 1.4 1.08 1.44 1.571 2.235 2.2 1.27 4 2\tabcellsep https://co mmons.ap ache.org https://sou rceforge.n et/projects /math4j https://sou rceforge.n et/projects / j https://sou rceforge.n / https://sou rceforge.n et/projects ber /newsgrab\tabcellsep Global Journal of Computer Science and Technology\\
\tabcellsep OptionsPanel\tabcellsep 363\tabcellsep 75\tabcellsep 214\tabcellsep 15\tabcellsep 4\tabcellsep 9.8\tabcellsep \tabcellsep \\
Jipa\tabcellsep Label\tabcellsep 18\tabcellsep 11\tabcellsep 42\tabcellsep 3\tabcellsep 4\tabcellsep 1.8\tabcellsep https://sou\tabcellsep \\
\tabcellsep Variable\tabcellsep 40\tabcellsep 23\tabcellsep 87\tabcellsep 3\tabcellsep 4\tabcellsep 2.1\tabcellsep rceforge.n\tabcellsep \\
Total\tabcellsep \tabcellsep 2762\tabcellsep 943\tabcellsep 5021\tabcellsep 111\tabcellsep 264\tabcellsep \tabcellsep /\tabcellsep \end{longtable} \par
  {\small\itshape [Note: C© 2016 Global Journals Inc. (US)]} 
\caption{\label{tab_4}Table II :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{lll} \par 
\begin{longtable}{P{0.8229828850855746\textwidth}P{0.027017114914425426\textwidth}}
Parameter\tabcellsep Value\\
Population Size\tabcellsep 10\\
Search Budget\tabcellsep 600s\\
Maximal number of generations/target\tabcellsep 10\\
b) Experiment\tabcellsep \\
\multicolumn{2}{l}{For each of the classes we run eToc with the}\\
following configurations:\tabcellsep \\
\multicolumn{2}{l}{1. Original Fitness (OF) function with search}\\
budget of 2 min\tabcellsep \\
\multicolumn{2}{l}{2. Proposed Fitness (PF) function with search}\\
budget of 2 min\tabcellsep \\
\multicolumn{2}{l}{3. Original Fitness (OF) function with search}\\
budget of 10 min\tabcellsep \\
\multicolumn{2}{l}{4. Proposed Fitness (PF) function with search}\\
budget of 2 min\tabcellsep \end{longtable} \par
 
\caption{\label{tab_5}Table lll :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{IV} \par 
\begin{longtable}{P{0.04950950337216432\textwidth}P{0.3913856529736358\textwidth}P{0.042213366033108525\textwidth}P{0.01771919068056407\textwidth}P{0.08859595340282035\textwidth}P{0.025536480686695277\textwidth}P{0.026057633353770693\textwidth}P{0.018240343347639486\textwidth}P{0.0187614960147149\textwidth}P{0.02709993868792152\textwidth}P{0.018240343347639486\textwidth}P{0.014071122011036172\textwidth}P{0.039607602697731455\textwidth}P{0.022409564684242798\textwidth}P{0.03908645003065604\textwidth}P{0.011465358675659103\textwidth}}
\tabcellsep \multicolumn{13}{l}{A Fitness Function for Search-Based Testing of Java Classes, which is Based on the States Reached by the}\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \multicolumn{4}{l}{Object under Test}\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \\
\tabcellsep \multicolumn{4}{l}{VII. ExponentialFunction 100 100 EXPERIMENTAL EVALUATION 100}\tabcellsep 100\tabcellsep 60\tabcellsep 55\tabcellsep 60\tabcellsep 60\tabcellsep 8\tabcellsep \tabcellsep 16\tabcellsep 7\tabcellsep 15\\
\tabcellsep ArrayUtil\tabcellsep 100\tabcellsep 99\tabcellsep 100\tabcellsep 100\tabcellsep 9\tabcellsep 9\tabcellsep 9\tabcellsep 9\tabcellsep \multicolumn{2}{l}{64}\tabcellsep 141\tabcellsep 64\tabcellsep 141\\
\tabcellsep PolyFunction\tabcellsep -\tabcellsep -\tabcellsep 85\tabcellsep 87\tabcellsep -\tabcellsep -\tabcellsep 31\tabcellsep 38\tabcellsep \multicolumn{2}{l}{27}\tabcellsep 89\tabcellsep 30\tabcellsep 98\\
\tabcellsep Complex\tabcellsep \multicolumn{2}{l}{100 100}\tabcellsep 100\tabcellsep 100\tabcellsep 34\tabcellsep 37\tabcellsep 34\tabcellsep 37\tabcellsep \multicolumn{2}{l}{13}\tabcellsep 27\tabcellsep 12\tabcellsep 31\\
\tabcellsep StringTokenizer\tabcellsep 65\tabcellsep 65\tabcellsep 69\tabcellsep 69\tabcellsep 15\tabcellsep 21\tabcellsep 19\tabcellsep 23\tabcellsep 8\tabcellsep \tabcellsep 18\tabcellsep 16\tabcellsep 33\\
\tabcellsep GAAlgorithm\tabcellsep 93\tabcellsep 93\tabcellsep 93\tabcellsep 93\tabcellsep 33\tabcellsep 33\tabcellsep 33\tabcellsep 50\tabcellsep \multicolumn{2}{l}{10}\tabcellsep 21\tabcellsep 8\tabcellsep 19\\
\tabcellsep Genome\tabcellsep 44\tabcellsep 44\tabcellsep 55\tabcellsep 55\tabcellsep 0\tabcellsep 4\tabcellsep 0\tabcellsep 4\tabcellsep 3\tabcellsep \tabcellsep 6\tabcellsep 4\tabcellsep 10\\
\tabcellsep Population\tabcellsep 92\tabcellsep 92\tabcellsep 100\tabcellsep 100\tabcellsep 32\tabcellsep 32\tabcellsep 32\tabcellsep 32\tabcellsep \multicolumn{2}{l}{11}\tabcellsep 29\tabcellsep 11\tabcellsep 29\\
\tabcellsep ExplorerFrame\tabcellsep 8\tabcellsep 15\tabcellsep 8\tabcellsep 15\tabcellsep 0\tabcellsep 3\tabcellsep 0\tabcellsep 3\tabcellsep 2\tabcellsep \tabcellsep 2\tabcellsep 2\tabcellsep 3\\
Year 2016\tabcellsep \multicolumn{2}{l}{ObjectViewManager 54 DirectoryDialog 6 NewsFactory -}\tabcellsep 54 6 -\tabcellsep 54 6 -\tabcellsep 54 6 -\tabcellsep 17 0 -\tabcellsep 24 0 -\tabcellsep 17 0 -\tabcellsep 24 0 -\tabcellsep 2 5 -\tabcellsep \tabcellsep 3 11 -\tabcellsep 2 5 -\tabcellsep 3 11 -\\
12\tabcellsep SongInfo BatchJob\tabcellsep \multicolumn{2}{l}{50 100 100 50}\tabcellsep 50 100\tabcellsep 50 100\tabcellsep 22 62\tabcellsep 27 69\tabcellsep 24 62\tabcellsep 27 69\tabcellsep \multicolumn{2}{l}{5 10}\tabcellsep 12 20\tabcellsep 8 9\tabcellsep 19 22\\
Volume XVI Issue II Version I\tabcellsep StringSorter OptionPanel Label Variable Average Total\tabcellsep \multicolumn{2}{l}{100 100 --100 100 100 100 60.5 69 --}\tabcellsep \multicolumn{6}{l}{100 37 100 100 74.8 75.2 37.9 42.7 35.9 41.5 100 17 17 17 17 37 --3 9 100 55 55 55 55 100 55 56 56 59 ------}\tabcellsep \multicolumn{2}{l}{6 7 4 6 -290}\tabcellsep 17 21 16 9 -693\tabcellsep 6 8 4 9 -314\tabcellsep 17 19 16 19 -781\\
Global Journal of Computer Science and Technology C ( )\tabcellsep \multicolumn{8}{l}{Average Of All Runs For Each Cut BC with PF (2 min) BC with OF (10 BC with PF (10 MS with OF (2 MS with PF (2 MS with OF (10 100 100 100 29 72 29 RQ1: How does the usage of the proposed fitness Class BC with OF (2 min) Staku 100 function affect the branch coverage?}\tabcellsep \multicolumn{2}{l}{MS with PF (2 72}\tabcellsep No. test with OF 2\tabcellsep \multicolumn{2}{l}{Test length with OF 8}\tabcellsep No. test with PF 4\tabcellsep Test length with PF 15\\
\tabcellsep Option\tabcellsep 69\tabcellsep 69\tabcellsep 69\tabcellsep 69\tabcellsep 41\tabcellsep 49\tabcellsep 41\tabcellsep 49\tabcellsep \tabcellsep 62\tabcellsep 147\tabcellsep 71\tabcellsep 166\\
\tabcellsep TypeHandler\tabcellsep 75\tabcellsep 75\tabcellsep 75\tabcellsep 75\tabcellsep 46\tabcellsep 46\tabcellsep 46\tabcellsep 46\tabcellsep \tabcellsep 12\tabcellsep 24\tabcellsep 12\tabcellsep 24\\
\tabcellsep \multicolumn{2}{l}{AlreadySelectedException 100}\tabcellsep 100\tabcellsep 100\tabcellsep 100\tabcellsep \multicolumn{5}{l}{100 100 100 100}\tabcellsep 3\tabcellsep 5\tabcellsep 3\tabcellsep 5\\
\tabcellsep OptionGroup\tabcellsep 100\tabcellsep 100\tabcellsep 100\tabcellsep 100\tabcellsep 84\tabcellsep 89\tabcellsep 84\tabcellsep 89\tabcellsep \tabcellsep 8\tabcellsep 27\tabcellsep 7\tabcellsep 35\\
\tabcellsep Rational\tabcellsep 94\tabcellsep 94\tabcellsep 94\tabcellsep 94\tabcellsep 75\tabcellsep 79\tabcellsep 75\tabcellsep 79\tabcellsep \tabcellsep 12\tabcellsep 24\tabcellsep 12\tabcellsep 31\\
\tabcellsep ExponentialFunction\tabcellsep 100\tabcellsep 100\tabcellsep 100\tabcellsep 100\tabcellsep 60\tabcellsep 55\tabcellsep 60\tabcellsep 60\tabcellsep \tabcellsep 8\tabcellsep 16\tabcellsep 7\tabcellsep 15\\
\tabcellsep © 2016 Global Journals Inc. (US) 1\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \end{longtable} \par
 
\caption{\label{tab_6}Table IV :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{P{0.85\textwidth}}
Year 2016\\
13\\
( )\end{longtable} \par
  {\small\itshape [Note: C© 2016 Global Journals Inc. (US)]} 
\caption{\label{tab_7}Table 2 .}\end{figure}
 			\footnote{RQ1: In our experiments, there is no difference in the average branch coverage achieved between the usage of the original fitness function and the proposed fitness function.} 			\footnote{RQ2: In our experiments, the usage of the proposed fitness function results in a relative increase of 15.6\% in the average mutation score achieved against the original fitness function.RQ3: In our experiments, the usage of the proposed fitness function results in a relative increase of 8.2\% in the average number of test cases and 12.6\% in the average test suite size achieved against the original fitness function.} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Tracey ()]{b17}\label{b17} 	 		\textit{A Search-Based Automated Test-Data Generation Framework For Safety-Critical Software},  		 			N Tracey 		.  		2000.  		 			University of York 		 	 	 (PhD thesis) 
\bibitem[A simple and practical approach to unit testing: The JML and JUnit way The Economic Impacts of Inadequate Infrastructure for Software Testing (2001)]{b0}\label{b0} 	 		‘A simple and practical approach to unit testing: The JML and JUnit way’.  		 01-12.  	 	 		\textit{The Economic Impacts of Inadequate Infrastructure for Software Testing},  				Nov. 2001.  		 			NIST (National Institute of Standards and Technology ; Department of Computer Science, Iowa State University 		 	 	 (Technical Report) 
\bibitem[Fraser and Arcuri ()]{b13}\label{b13} 	 		‘Achieving Scalable Mutationbased Generation of Whole Test Suites’.  		 			G Fraser 		,  		 			A Arcuri 		.  	 	 		\textit{Empirical Software Engineering},  				2014.  	 
\bibitem[Lakhotia et al. ()]{b9}\label{b9} 	 		‘An empirical investigation into branch coverage for C programs using CUTE and AUSTIN’.  		 			K Lakhotia 		,  		 			P Mcminnb 		,  		 			M Harman 		.  	 	 		\textit{Journal of Systems and Software}  		2010.  	 
\bibitem[Lakhotia et al. ()]{b16}\label{b16} 	 		‘AUSTIN: A Tool for Search Based Software Testing for the C Language and Its Evaluation on Deployed Automotive Systems’.  		 			K Lakhotia 		,  		 			M Harman 		,  		 			H Gross 		.  	 	 		\textit{International Symposium on SBSE},  				2010.  	 
\bibitem[Rojas et al. ()]{b15}\label{b15} 	 		‘Combining Multiple Coverage Criteria in Search-Based Unit Test Generation’.  		 			J Rojas 		,  		 			J Campos1 		,  		 			M Vivanti 		,  		 			G Fraser 		,  		 			A Arcuri 		.  	 	 		\textit{Proceedings of the 26th IEEE/ACM International Conference on Automated Software Engineering (ASE)},  				 (the 26th IEEE/ACM International Conference on Automated Software Engineering (ASE))  		2011. p. .  	 
\bibitem[Papadhopulli and Meçe (2015)]{b14}\label{b14} 	 		‘Coverage Criteria for Search Based Automatic Unit Testing of Java Programs’.  		 			E Papadhopulli 		,  		 			Meçe 		.  	 	 		\textit{International Journal of Computer Science and Software Engineering}  		October 2015. 4  (10) .  	 
\bibitem[Ma and Ouffut (2014)]{b25}\label{b25} 	 		\textit{Description of Class Mutation Mutation Operators for Java},  		 			Y Ma 		,  		 			J Ouffut 		.  		August 2014.  	 
\bibitem[Shamshiri et al. ()]{b6}\label{b6} 	 		‘Do Automatically Generated Unit Tests Find Real Faults? An Empirical Study of Effectiveness and Challenges’.  		 			S Shamshiri 		,  		 			R Just 		,  		 			J Rojas 		,  		 			G Fraser 		,  		 			P Mcminn 		,  		 			A Arcuri 		.  	 	 		\textit{Proceedings of the 30th IEEE/ACM International Conference on Automated Software Engineering (ASE)},  				 (the 30th IEEE/ACM International Conference on Automated Software Engineering (ASE))  		2015.  	 
\bibitem[Fraser et al. ()]{b5}\label{b5} 	 		‘Does Automated Unit Test Generation Really Help Software Testers? A Controlled Empirical Study’.  		 			G Fraser 		,  		 			P Mcminn 		,  		 			A Arcuri 		,  		 			M Staats 		.  	 	 		\textit{ACM Transactions on Software Engineering and Methodology}  		2015.  	 
\bibitem[Tsuji and Akinyele (2007)]{b4}\label{b4} 	 		‘Evaluation of AgitarOne’.  		 			T Tsuji 		,  		 			A Akinyele 		.  	 	 		\textit{Analysis of Software Artifacts Final Project Report},  				April 24. 2007.  	 
\bibitem[Wegener et al. (2001)]{b18}\label{b18} 	 		‘Evolutionary Test Environment for Automatic Structural Testing’.  		 			J Wegener 		,  		 			A Baresel 		,  		 			H Sthamer 		.  	 	 		\textit{Information and Software Technology Special Issue on Software Engineering using Metaheuristic Innovative Algorithms},  				December 2001. 43 p. .  	 
\bibitem[Tonella]{b20}\label{b20} 	 		‘Evolutionary Testing of Classes’.  		 			P Tonella 		.  	 	 		\textit{Proceedings of International Symposium on Software Testing and Analysis (ISSTA)},  				 (International Symposium on Software Testing and Analysis (ISSTA))  		p. 2004.  	 
\bibitem[Mirazz ()]{b10}\label{b10} 	 		\textit{Evolutionary Testing of Stateful Systems: a Holistic Approach},  		 			M Mirazz 		.  		2010.  		 			University of Torino 		 	 	 (PhD thesis) 
\bibitem[Fraser and Arcuri]{b3}\label{b3} 	 		‘EvoSuite at the SBST 2015 Tool Competition’.  		 			G Fraser 		,  		 			A Arcuri 		.  	 	 		\textit{Proceedings of International Conference in Software Engineering (ICSE)},  				 (International Conference in Software Engineering (ICSE))  		p. 2015.  	 
\bibitem[Pacheco et al.]{b2}\label{b2} 	 		‘Feedback-directed Random Test Generation’.  		 			C Pacheco 		,  		 			S Lahiri 		,  		 			M Ernst 		.  	 	 		\textit{Proceedings of International Conference in Software Engineering (ICSE)},  				 (International Conference in Software Engineering (ICSE))  		p. 2007.  	 
\bibitem[Fraser and Arcuri ()]{b27}\label{b27} 	 		‘Handling test length bloat’.  		 			G Fraser 		,  		 			A Arcuri 		.  	 	 		\textit{Proceedings of ICST},  				 (ICST)  		2013.  	 
\bibitem[Arcuri ()]{b19}\label{b19} 	 		‘It Does Matter How You Normalise the Branch Distance in Search Based Software Testing’.  		 			Arcuri 		.  	 	 		\textit{Third International Conference on Software Testing, Verification and Validation},  				2010.  	 
\bibitem[Dallmeier et al. ()]{b28}\label{b28} 	 		‘Mining Object Behaviour with ADABU’.  		 			V Dallmeier 		,  		 			C Lindig 		,  		 			A Vasilowski 		.  	 	 		\textit{Proceedings of the International Workshop on Dynamic Systems Analysis},  				 (the International Workshop on Dynamic Systems Analysis)  		2006.  	 
\bibitem[Le et al. ()]{b26}\label{b26} 	 		‘MuCheck: An Extensible Tool for Mutation Testing of Haskell Programs’.  		 			D Le 		,  		 			M Alipour 		,  		 			R Gopinath 		,  		 			A Groce 		.  	 	 		\textit{Proc. of the International Symposium on Software Testing and Analysis},  				 (of the International Symposium on Software Testing and Analysis)  		2014.  	 
\bibitem[Fraser and Zeller ()]{b11}\label{b11} 	 		‘Mutation-Driven Generation of Unit Tests and Oracles’.  		 			G Fraser 		,  		 			A Zeller 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		2012.  	 
\bibitem[Eiben and Smit ()]{b24}\label{b24} 	 		‘Parameter tuning for configuring and analyzing evolutionary algorithms’.  		 			E Eiben 		,  		 			S K Smit 		.  	 	 		\textit{Journal: Swarm and Evolutionary Cmputation}  		2011. p. .  	 
\bibitem[Rountev ()]{b21}\label{b21} 	 		‘Precise identification of side-effect-free methods in java’.  		 			Rountev 		.  	 	 		\textit{20th IEEE International Conference on Software Maintenance (ICSM '04)},  				2004. p. .  	 
\bibitem[Salcianu and Rinard (2005)]{b22}\label{b22} 	 		‘Purity and side effect analysis for java programs’.  		 			M Salcianu 		,  		 			Rinard 		.  	 	 		\textit{Proceedings of the 6th International Conference on Verification, Model Checking and Abstract Interpretation},  				 (the 6th International Conference on Verification, Model Checking and Abstract Interpretation)  		January 2005. p. .  	 
\bibitem[Mcminn (2004)]{b8}\label{b8} 	 		‘Search-based Software Test Data Generation: A Survey’.  		 			P Mcminn 		.  	 	 		\textit{Software Testing, Verification and Reliability},  				June 2004. p. .  	 
\bibitem[Gross et al. ()]{b7}\label{b7} 	 		‘Search-based system testing: high coverage, no false alarms’.  		 			F Gross 		,  		 			G Fraser 		,  		 			A Zeller 		.  	 	 		\textit{Proceedings of International Symposium on Software Testing and Analysis (ISSTA)},  				 (International Symposium on Software Testing and Analysis (ISSTA))  		2012.  	 
\bibitem[Tonella ()]{b12}\label{b12} 	 		\textit{Search-Based Test Case Generation},  		 			P Tonella 		.  		2013. TAROT Testing School Presenetation.  	 
\bibitem[Cadar and Sen ()]{b1}\label{b1} 	 		‘Symbolic Execution for Software Testing: Three Decades Later’.  		 			C Cadar 		,  		 			K Sen 		.  	 	 		\textit{Communications of ACM}  		2013. p. .  	 
\bibitem[Aleti and Grunske ()]{b23}\label{b23} 	 		‘Test Data Generation with a Kalman Filter-Based Adaptive Genetic Algorithm’.  		 			L Aleti 		,  		 			Grunske 		.  	 	 		\textit{Journal of Systems and Software}  		2014.  	 
\bibitem[Papadhopulli and Frasheri ()]{b29}\label{b29} 	 		‘Today's Challenges of Symbolic Execution and Search-Based for Automated Structural Testing’.  		 			N Papadhopulli 		,  		 			Frasheri 		.  	 	 		\textit{Proceedings of ICTIC},  				 (ICTIC)  		2015.  	 
\end{bibitemlist}
 			 		 	 
\end{document}
