3.1 Forward Reachability Analysis

Yih-Farn Chen et al. [⁹] basically found the representation logics that are used for reachability of code and detection of unreachable code techniques. These two tasks help to eliminate excess software baggage and holds software reuse metrics.

Forward Reachability Analysis is used for detecting dead code by determining a Reachable Entity Set and computing software reuse metrics. The reuse metrics is used to compute the code reuse and improve the quality and productivity. Reuse metrics consists of cost benefit analysis, percentage of reuse, reusability assessment, maturity assessment and failure modes analysis. There are two choices based on reachability of code and are described as follows:

Class Tree {

     Public:

     Tree (int);

     Tree (Char*, Tree);

     Tree (Char*, Tree, Tree);

     Tree (Char*, Tree, Tree, Tree);

     Tree (Const Tree & a);

     ~Tree () {

     if (-–b->use == 0)

     delete b;}};

     void operator = (const Tree & a);

     main () {

     Tree t = Tree (“-”, Tree (“*”, 7), Tree (“+”, 5, 3), Tree (“-”, 4, 5, 6));

     cout<< t << “\n”;

     t = Tree (“-”, t, t);

     cout<< t << “\n”;

     t = Tree (“+”, t, t, t);

     cout<<t<<”\n”;}

3.2 Reverse Reachability Analysis

Various authors have examined to use this technique of reachability code analysis. Researchers have found to support the complete reachability analysis that has been defined as an objective patterns at the selected abstraction level so that the programmers has the ability to analyze the different safeness implementations.

Reverse Reachability Analysis helps programmers to determine all the program entities that are dependent on an entity either directly or indirectly. If BinTree::size is altered, then other entities in the graph may be affected and is shown as in Fig. 3.

Fig. 2 Shows that all the members of the test class are exercised for the sample Tree class 

Fig. 3 Dependencies of Program entities on BinTree: size i.e. directly or transitively 

3.3 Visibility Analysis

Gansner et al. [⁹] accomplishes the reachability investigation on the regulation relationship in the class legacy chain of importance and discovers all part capacities and factors obvious to class BinaryNode in Koenig's illustration [¹⁰]. Regulation relationship happens between each parent class and a part.

Perceivability Analysis settles which part capacities and factors in a class legacy chain of command are seeable to a determined class. All part capacities in BinaryNode are seeable to itself. All open and shielded individuals from Node are likewise noticeable to BinaryNode on the grounds that BinaryNode has an open legacy association with Node.

Likewise, Node is a companion of Tree and along these lines all individuals from Tree are noticeable to Node. The visibility analysis of BinaryNode and Node is shown in Fig. 4.

Fig. 4 Visibility analysis of BinaryNode and Node 

4.1 Dynamic Symbolic Execution (DSE)

Data Flow Testing (DFT) [⁶] focuses on introducing a hybrid DFT structure. The heart of the structure is based on DSE and checks the reachability in software model checking to improve the testing performance.

DSE is a dynamic approach. It is a novel and efficient approach for automatic generation of the test cases. It combines the classical symbolic execution with real execution and generates many possible program pathways in the given amount of time. It aims at covering feasible pairs.

It takes the desired def-use pair du (ld, lu, x) as input and the Control Flow Graph (CFG) is constructed. It determines the test case for feasible test objectives and removes infeasible test objectives. It starts with arbitrary test input values. These test input values cause the execution path to cover the def-use pair. There are two approaches to deal with this problem.

Firstly we remove the invalid branching nodes by redefinition pruning technique and secondly, it applies Cut-Point Guided Search (CPGS) to choose which branching point to initially take. This approach can develop the DFT by 60-80% as compared to the testing span.The search results shows that the Dynamic Symbolic Execution approach reduces the DFT by 40% as compared to testing span to improve the testing performance than the Counter Example-Guided Abstraction Refinement (CEGAR) based approach.

Path explosion is a challenging problem in this approach because in a cheap amount of time to trigger the desired pair. Henceforth, more work will be done based on this approach to enhance the data flow testing technique on large programs. Fig. 5 shows the workflow of DSE.

Fig. 5 Workflow of Dynamic Symbolic Execution 

It starts with an arbitrary test inputs values followed by an execution path. Then, it removes the invalid branching nodes by redefinition pruning technique and finds the known paths by generating the constraint system.

4.2 Counter Example-Guided Abstraction Refinement (CEGAR)

CEGAR [⁶] is a static approach. It is utilized for creating the experiments and checking the fleeting wellbeing properties of the product. Here, a source program and an impermanent wellbeing determination is taken, which either demonstrates that the program fulfills the particular or produces a counter example to show the infringement.

This approach works in two stages: show checking and experiment created from the counterexamples. It first begins with a base or coarse program deliberation and over and again channels it so as to test for infeasible combine. We have to set a checkpoint to decide if the variable banner is valid.

The defutilize match is infeasible when the check point is inaccessible and a counterexample is returned when the def-utilize combine is attainable.

This approach is more intense than DSE approach as it enhances the scope by 20%. Consequently, more work will be done to make a profound correlation between both the methodologies. The workflow of CEGAR is shown in Fig. 6.

Fig. 6 Workflow of Counter Example-Guided Abstraction Refinement 

A C program is taken as input to the abstract model.

It then goes to the model checker where it automatically checks whether the model satisfies the given requirements and generates no error or bug found.

Then by the help of model checker, it goes to the simulator by taking counterexample as input where a program allows a computer to execute programs written for a different operating system by generating the simulation successfully and detecting the bug.

After that it goes to the refinement process where it removes the invalid the execution paths.

4.3 Document-Assisted Symbolic Execution (DASE)

DASE [³] is another novel approach for programmed age of the experiments and mistake recognizable proof to expand the adequacy and effectiveness of the representative execution. DASE separates the information impulse from archives consequently and afterward utilizes the info impulse to center around testing mistake dealing with codes, which are vital that assistance the inquiry systems to enhance the representative execution and process the execution ways.

A program report is given as info that naturally separates the information impulse from that. There are two classes of info impulse: the setup of an information record and the substantial information estimations of order line decision.

The outcome shows that when contrasted with KLEE, DASE recognized 12 obscure imperfections that KLEE neglected to distinguish and out of 88 just 6 have been affirmed by the engineers.

DASE improves line investigation, branch examination and call investigation by 14.2–120.3%, 2.3–167.7%, and 16.9–135.2% in contrast with KLEE. Testing with invalid information is a testing issue. Subsequently, keeping in mind the end goal to test a program with invalid info esteems DASE approach centers by counterbalancing the information requirements.

4.4 Directed Automated Random Testing (DART)

DART [¹¹] approach is also known as Concolic testing [¹⁴]. It dynamically operates the symbolic execution when the program is accomplished on real values. It supports two events: a real event and a symbolic event. A real event outlines all mutable to the real values and a symbolic event an outline all mutable to the non-real values.

A program is taken as input and the corresponding symbolic execution tree is drawn. It first starts with the generation of random inputs and execute the program concretely and symbolically. At each branch point, either it will follow the true path or it will end with the false path and generates the Path Condition (PC) for each path.

It finally surveys that all the paths of the program are examined and generates the test inputs. Path explosion and constraint solving is a challenging problem. There are two approaches to solve the path explosion problem: heuristics approach and sound program analysis approach.

There are two approaches to solve the constraint solving problem: irrelevant constraint elimination approach and incremental solving. Hence, more research can be performed for automatic generatation of test inputs that covers the software bugs; generates the test suite that achieves high coverage; gives per-path guarantees and finding defects in software from low-level to high-level application programs.

The program analyzer which analyzes the behavior of the computer programs is divided into two parts. The first part is path selector in which control flow graph is taken as input and the second part is test data generator in which both control flow graph and data dependence is taken as input.

Data dependence is a condition where the program instruction refers to the data of the previous instructions. Then the path selector generates the selected paths and goes to the test data generator where the selected path information is taken as input to the path selector and produces the test data. Fig. 7 shows the workflow of DART.

Fig. 7 Workflow of directed automated random testing 

4.5 Executed-Generated Testing (EGT)

EGT approach [¹⁵] is the instance of the modern symbolic execution techniques. It functions entirely between the real event and the symbolic event of the program. A source program is given as input and operated in the same program when the values are real.

It has the ability to mix both real and symbolic execution dynamically before finding all actions when the input values are all real. If so, then the action is executed in the same program or if more than one value is symbolic, the operation is executed symbolically by maintaining a path condition for each path.

The disadvantages of this approach are elimination of irrelevant constraints, path explosion and memory modeling.

Hence, more research can be done in contributing a fashion to develop the test inputs that finds the errors which ranges from low to high-level syntactic features. Fig. 8 shows the workflow of EGT.

Fig. 8 Workflow of executed-generated testing 

4.6 conc-iSE: Incremental Symbolic Execution Approach of Concurrent Programs

Incremental Symbolic Execution approach [¹⁶] for simultaneous programming is an approach to produce new test contributions by investigating the new execution ways between the two program variants.

These two program renditions i.e., old program variant P and new program form P' with an arrangement of execution abstract of program P is taken as information and over and over break down the present execution ways utilizing P'. Its yield is to examine the new recognition in P'.

This could be conceivable by evacuating the excess execution ways by rundown based calculation.

Consequently, amid the representative execution of P′, it breaks the regressive change-affect investigation. In this investigation, it fundamentally measures the arrangement of directions that may influence the changed guidelines set up of estimating the arrangement of guidelines that may be influenced by the changed directions [¹⁷].

The outcome demonstrates that this approach would overall be able to lessen the emblematic execution time and to expel the excess execution ways and string interleaving in the incremental representative execution.

The upper piece of the figure begins with the two program variants i.e., old program form P and new program adaptation P' with an arrangement of execution summation of program P is taken as info and more than once examine the present execution ways utilizing P' and produces the new recognition in P' by pruning the repetitive states or execution ways.

The lower some portion of the figure begins with a subjective current test inputs. Amid the representative execution, the new states are created and each new state produces another match incorporates the information info and string interleaving to touch base at the new state. The workflow of conc-iSE is shown in Fig. 9.

Fig. 9 Workflow of incremental symbolic execution 

4.7 Loop-Extended Symbolic Execution (LESE)

Another representative execution strategy called LESE is proposed in [¹⁸] that sums up from the genuine execution to an arrangement of program executions that includes the distinctive number of redundancies for each circle as in the underlying execution.

Circle Extended Symbolic Execution is utilized to acquire appropriate outcomes when contrasted with emblematic execution when it is utilized as a part of projects with circles.

It makes mistake recognizing apparatuses more proficient and permits age of the experiments to achieve high test scope as fast as could reasonably be expected. A source program with circles is adopted as contribution to this strategy.

It begins with the predicate which is otherwise called inquiry predicate.

The predicate might be the branch condition related with the program point, and an execution that achieves the point, yet does not fulfill the predicate and after that yields to determine that the condition on a contribution to the program which creates the execution brings about a similar way and furthermore points the predicate to be valid.

It has the issue of recognizing and deciding support abundance impulse that produces on unmodified Windows and Linux sets.

The outcome demonstrates that the Loop-Extended Symbolic Execution can make an assortment of program examination, including the security applications, faster and more productive 19]. The workflow of LESE is shown in Fig. 10.

Fig. 10 Workflow of Loop-Extended Symbolic Execution