White box testing

White-box testing (also known as clear box testing, glass box testing, and transparent box testing and structural testing) is a method of testing software that tests internal structures or workings of an application.
While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level.
White-box test design techniques include:
• Control flow testing
• Data flow testing
• Branch testing
• Path testing
• Statement coverage
• Decision coverage

Control flow testing:
The “Basic idea” behind Control Flow Testing is to “select paths” as test cases and come up with the inputs (input values) to execute through those paths. It includes the following 4 steps:
Build the Control Flow Diagram (CFD)
Select the paths in the (CFD) to cover for the testing
Pick or develop the input values for testing the chosen paths
Analyze the test results

Data flow testing: Data Flow testing is basically a white box testing approach. In this we test the variables definitions and their uses in the program to find out the anomalies like:
1. Variable defined but not used.
2. Variable used but not defined.
3. Variable has been defined twice before using.

Branch Coverage:
-Achieved when every branch from a node is executed at least once by a test suite.
- Also known as decision coverage or all-edge coverage.
-Improve on statement coverage by requiring that each branch be taken at least once. Hence each outcome of a predicate expression is exercised at least once (i.e., true and false).
- However, it is limited by the fact that it treats a compound predicate as a single statement: branch coverage may be achieved without exercising all of the conditions

Example:
int foo(int x)
{
if (a==b || (x==y && isEmpty()))
{ ++x; }
else { –x; }
return x;
}
- Branch coverage misses several of the possible entry-exit paths. Branch coverage may be
Achieved using:
1.a ==b
2.a !=b and x !=y
Without ever exercising this.isEmpty()
Path: starts with the entry node, follows through a number of links and nodes, and ends up in an exit node; we are interested “logical” paths.

Statement coverage:
-Achieved when all statements in a method have been executed at least once.
-Also known as line coverage, segment coverage, or basic block coverage.
-Segment and basic block coverages count segments instead of individual statements.
-Segment coverage ensures that all code segments defined in the CFG are covered.
Example:
int foo(int x) {
if (a==b) { ++x; }

else { –x;}
return x;
}
Statement coverage is achieved by having test cases involving both:
1.a==b
2.a != b

Test Coverage Overview:
-Test coverage attempts to address questions about when to stop testing, or the amount of testing that is enough for a given program.
-Ideal testing is to explore exhaustively the entire test domain, which in general is impossible.
-Some code may never be executed due to the possibility of missing test cases.
-Effectiveness of test suites can be established only by knowing what code is, or isn’t executed.

Review Questions:
-Example int foo(int x) { if (a==b || (x==y && isEmpty())) { ++x; } else { –x; } return x; }
Mark each of the following as true or false:
(1)Segment coverage implies statement coverage .
(2)Branch coverage implies segment coverage
(3)Branch coverage implies multiple conditional coverage
(4)Multiple conditional coverage implies branch coverage
(5)Path coverage implies branch coverage
(6)All def-use path coverage implies all definition coverage
Result: T T F T T T
-What test cases will give 100% branch coverage? -Does this achieve 100% multiple conditional coverage?
-Which coverage criteria should be used here to maximize coverage?

What do you understand of cost/performance Trade off model for pipeline processor designed?

In the hardware design of a pipeline system, trade off between cost and performance
must be considered. A cost/performance trade off model for pipeline design has been proposed by Peter Kogge.

A cost/performance trade off model for pipeline can be rewritten as

………………………………………………………………………..
G = The cost of a non-pipelined design
L= The cost of adding each latch
T= The latency in the non-pipeline system is T.
S= The delay due to the addition of the latch.
C= The cost for a *-stage pipeline design.

Which is plotted in Figure 2.3 for two sets of sample values of G, L, T, and S.

Simulated Annealing – Solving the Travelling Salesman Problem (TSP).

Travelling Salesman Problem:
A salesman wants to travel to N cities (he should pass by each city). How can we order the cities so that the salesman’s journey will be the shortest? The objective function to minimize here is the length of the journey (the sum of the distances between all the cities in a specified order).
To start solving this problem; we need:
• Configuration setting: This is the permutation of the cities from 1 to N, given in all orders. Selecting an optimal one between these permutations is our aim.
• Rearrangement strategy: The strategy that we will follow here is replacing sections of the path, and replacing them with random ones to retest if this modified one is optimal or not.
• The objective function (which is the aim of the minimization): This is the sum of the distances between all the cities for a specific order.
Simulated Annealing:
Simulated Annealing was given this name in analogy to the “Annealing Process” in thermodynamics, specifically with the way metal is heated and then is gradually cooled so that its particles will attain the minimum energy state (annealing). Then, the aim for a Simulated Annealing algorithm is to randomly search for an objective function (that mainly characterizes the combinatorial optimization problem).
Simulated Annealing’s advantage over other methods is the ability to obviate being trapped in local minima. In here, we mean that the algorithm does not always reject changes that decrease the objective function but also changes that increase the objective function according to its probability function:
P = exp (-∆f/T)
Where T is the control parameter (analogy to temperature) and ∆f is the variation in the objective function.
The probability function is definitely a derivative of the Boltzmann probability distribution function.
Here starting temperature = 400
The Code:
public string StartAnnealing()
{
TspDataReader.computeData();
ArrayList list = new ArrayList();
//primary configuration of cities
int [] current={0,1,2,3,4,5,6,7,8,9,10,11,12,13,14};
//the next configuration of cities to be tested
int []next=new int[15];
int iteration =-1;
//the probability
double proba;
double alpha =0.999;
double temperature = 400.0;
double epsilon = 0.001;
double delta;
double distance = TspDataReader.computeDistance(current);

//while the temperature did not reach epsilon
while(temperature > epsilon)
{
iteration++;
//get the next random permutation of distances
computeNext(current,next);
//compute the distance of the new permuted configuration
delta = TspDataReader.computeDistance(next)-distance;
//if the new distance is better accept it and assign it
if(delta<0)
{
assign(current,next);
distance = delta+distance;
}
else
{
proba = rnd.Next();
//if the new distance is worse accept
//it but with a probability level
//if the probability is less than
//E to the power -delta/temperature.
//otherwise the old value is kept
if(proba< Math.Exp(-delta/temperature))
{
assign(current,next);
distance = delta+distance;
}
}
//cooling process on every iteration
temperature *=alpha;
//print every 400 iterations
if (iteration%400==0)
Console.WriteLine(distance);
}
try
{
return "best distance is"+distance;
}
catch
{
return "error";
}
}

///

/// compute a new next configuration
/// and save the old next as current
///

/// current configuration /// next configuration void computeNext(int[] c, int[] n)
{
for(int i=0;i n[i]=c[i];
int i1 = (int)(rnd.Next(14))+1;
int i2 = (int)(rnd.Next(14))+1;
int aux = n[i1];
n[i1]=n[i2];
n[i2]=aux;
}
You could change the starting temperature, decrease or increase epsilon (the amount of temperature that is cooling off) and alter alpha to observe the algorithm’s performance.

Briefly explain the operation of following two pipeline processors:

MIPS R2000/3000 (5 – stages):
The MIPS R2OOO/R3O0O RISC processors employ a five-stage instruction pipeline. The MIPS architecture is load/store architecture. The IF and ID generic sub computations are merged into the IF stage, which will require one memory (I-cache) read in every machine cycle. The OF generic sub computation is carried out in both the RD and MEM stages.

MIPS processors normally employ separate instruction and data caches. In every machine cycle the R2O00/R3O00 pipeline must support the concurrent accesses of one I-cache read by the IF stage and one D-cache read (for a load instruction) or write (for a store instruction) by the MEM stage.

R2000 / R3000 : Frequency (MHz)> 8-40MHz , Process (nm) > 2000/1200 , Transistors (millions)> 0.11 , Pin Count >145, Power (W)>4 , D. cache (KB) > 32-64, I. cache (KB)> 64, L2 Cache > 0-256 KB , L3 Cache > None.

2. AMDAHL 470 V/7 (12 – stages pipeline):
AMDAHL 470V/7 is the 12-stage instruction pipeline. IF generic sub computation is implemented in the first three stages. Because of the complex addressing modes that ‘must be supported, the OF generic
sub computation is mapped into four stages. Both the EX and OS generic sub computations are partitioned into 12 pipeline stages. This 12-stage pipeline must support the concurrent accesses of two register reads by stage 5 and one register write by stage 12 in every machine cycle, along with four cache memory reads by stages 2, 3,7, and 8 in every machine cycle.