Module 4

Path Testing

• One of structured testing methodologies.
• White box testing or source code based testing.
• Use control flows
• Generates tests.

​

Path Testing

The groups of statements that make up a node in the Program Graph are called a basic block.

There is a straightforward algorithm to segment a code fragment into basic blocks and create the corresponding Program Graph.

Path testing process

1. Design control flow graph
2. Calculate Cyclomatic complexity
3. Generate set of paths
4. Test each path

​

Calculate Cyclomatic complexity

Formula

CC=E-N+2

​

where E=Number of edges

N=Number of nodes

CC is minimum number of test required for program/ algorithm unit.

Maximum of 3 number

int MAX (int a, int b, int c )

{

1. int max;

2. if(a>b && a>c)

3. max=a

4. else if (b>c)

5. max=b;

6. else max=c

7. return max;

}

​

​

�DD Paths �

The best-known form of structural testing is based on a construct known as a decision-to-decision path (DD-Path).

We will define DD-Paths in terms of paths of nodes in a directed graph. We might call these paths as chains, where a chain is a path in which the initial and terminal nodes are distinct, and every interior node has indegree = 1 and outdegree = 1.

​

DD Paths

​

• Structural testing is based on a construct known as a Decision to Decision Path.

​

• The name refers to a sequence of statements that begins with “outway“ of a decision statement and ends with “inway” of another decision statement.

DD Path

• Def: DD path in terms of path of nodes in a directed graph(chains).
• A chain is a path in which the initial and terminal nodes are distinct and every interior node has in degree=1 and out degree=1.
• Here line number refers to the statements and statement fragments.

In a program graph, non-executable statements such as variables and type declarations are not included.

Metric –Based Testing

• Statement and Predicate Coverage

Statement coverage based testing aims to devise test cases that collectively exercise all statements in a program - C_o

Predicate coverage (or branch coverage, or decision coverage) based testing aims to devise test cases that evaluate each simple predicate of the program to True and False - C₁

Condition Testing - C_1P

Decision coverage is good for exercising faults in the way a computation has been decomposed into cases.

• Condition coverage takes this decomposition in more detail, forcing execution of not only possible outcome of a Boolean expression but also of different combinations of the individual conditions in compound Boolean expression.
• A test suite T for a program P covers all C_1P iff for each atomic condition in P, it has at least two test cases in T : one forcing P to have true out come and the other one forcing P to have a false outcome.

Loop Coverage - C₂

Test cases that exercise the two possible outcomes of the decision of a loop condition, that is one to traverse the loop and the other to exit (or not enter) the loop.

• An extension would be to consider a modified boundary value analysis approach where the loop index is given a minimum, minimum +, a nominal, a maximum-, and a maximum value or even robustness testing.

​

• Once a loop is tested, then the tester can collapse it into a single node to simplify the graph for the next loop tests. In the case of nested loops we start with the inner most loop and we proceed outwards.
• If loops are knotted / unstructured then we must apply data flow analysis testing techniques.

​

Loop Testing.�

1. Program triangle 2 ‘Structured programming version of simpler specification

2. Dim a ,b, c As Integer

3. Dim IsATriangle As Boolean

‘ Step1 : Get Input

4. Output (“Enter 3 integers which are sides of a

triangle”)

5. Input(a ,b ,c)

6. Output (“Side A is”,a)

7. Output (“Side B is”,b)

8. Output (“Side C is”,c)

‘ Step2 : Is A Triangle ?

9. If (a < b + c) AND (b < a + c) AND (c < a + b)

10. Then IsATriangle = True

11. Else IsATriangle = False

12. EndIF

​

Step3 : Determine Triangle Type

13. If IsATriangle

14. Then If (a = b) AND (b = c)

15. Then Output (“Equilateral”)

16. Else If (a ≠ b) AND (a ≠ c) AND ( b ≠ c)

17. Then Output (“Scalene”)

18. Else Output (“Isosceles”)

19. EndIf

20. EndIf

21. Else Output (“Not a Triangle”)

22. EndIf

23.End triangle2

​

Traditional view of Testing Level

The traditional model of software development is the waterfall model which is drawn as V to perform basic level of testing.

The waterfall model is closely associated with top-down development and design by functional decomposition, where entire design is tree like structure.

The first level of testing involves analyzing each unit or an individual component of the software application.

Unit testing is also the first level of functional testing. The primary purpose of executing unit testing is to validate unit components with their performance.

A unit component is an individual function or regulation of the application, or we can say that it is the smallest testable part of the software. The reason of performing the unit testing is to test the correctness of inaccessible code.

Of the 3 traditional levels of testing(unit, integration and system), unit testing is best understood. Unit testing will help the test engineer and developers in order to understand the base of code that makes them able to change defect causing code quickly. The developers implement the unit.

​

The second level of software testing is the integration testing. The integration testing process comes after unit testing is mainly used to test the data flow from one module or component to other modules.

In integration testing, the test engineer tests the units or separate components or modules of the software in a group.

The primary purpose of executing the integration testing is to identify the defects at the interaction between integrated components or units.

​

The third level of software testing is system testing, which is used to test the software's functional and non-functional requirements.

It is end-to-end testing where the testing environment is parallel to the production environment. In the third level of software testing, we will test the application as a whole system.

To check the end-to-end flow of an application or the software as a user is known as System testing.

Test coverage metrics

It gives the information about covered and un covered areas in testing.

Test coverage metrics are a device to measure the extent to which a set of test cases covers a program.

​

Percen of coverage =no. of test area covered *100

total no. of test cases

Test coverage metrics

Why it is needed ?

• To find out the area which are in requirement document but not covered in test cases.
• It helps to measure the quality of the software.(many test cases left out=bad quality).

​

Approaches for Test Coverage Metrics