- Home
- Engineering
- Software Engineering : Software testing

prev

next

out of 21

Published on

22-Jan-2018View

106Download

6

Embed Size (px)

Transcript

Software Engineering Principles

Ajit K Nayak, Ph.D.

ajitnayak@soauniversity.ac.in

Software Testing

Acknowledgements Slides of Prof. Rajib Mall, IIT, KGP

Unit Testing Black-Box Testing

Two main approaches to design black box test

cases:

Equivalence class partitioning

Boundary value analysis

White-Box Texting

Designing white-box test cases:

requires knowledge about the internal structure of

software.

white-box testing is also called structural testing.

Equivalence Partitioning The input domain data is divided into different equivalence

data classes. used to reduce the total number of test cases to a finite set of

testable test cases, still covering maximum requirements.

Example: an input box accepting numbers from 1 to 1000 then there is no use in writing thousand test cases for all 1000 valid input numbers plus other test cases for invalid data.

test cases can be divided into three sets of input data called as classes. 1) One input data class with all valid inputs. Pick a single value

from range 1 to 1000 as a valid test case. If you select other values between 1 and 1000 then result is going to be same. So one test case for valid input data should be sufficient.

2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid input data test case.

3) Input data with any value greater than 1000 to represent third invalid input class.

Boundary Value Analysis Complements equivalence partitioning (typically

combined)

In practice, more errors found at boundaries of equivalence classes than within the classes

Divide input domain into equivalence classes

Also divide output domain into equivalence classes

Need to determine inputs to cover each output equivalence class

Again one test case per equivalence class

White-box testing : Statement coverage

Design test cases so that every statement in a program is executed at least once.

Statement coverage criterion

An error in a program can not be discovered unless

the part of the program containing the error is

executed.

Observing that a statement behaves properly for

one input value does not guarantee that it will

behave correctly for all input values.

Example: Euclid's GCD Algorithm

int f1(int x, int y){

1 while (x != y){

2 if (x>y) then

3 x=x-y;

4 else

5 y=y-x;

5 }

6 return x;

}

By choosing the test set

{(x=3,y=3),

(x=4,y=3),

(x=3,y=4)}

all statements are executed at least once.

White-box testing : Branch Coverage Test cases are designed such that:

different branch conditions given true and false

values in turn.

Branch testing guarantees statement coverage:

A stronger testing compared to the statement

coverage-based testing.

i.e. Test cases are a superset of a weaker testing:

discovers at least as many errors as a weaker testing

contains at least as many significant test cases as a

weaker test.

Example: Euclid's GCD Algorithm

int f1(int x, int y){

1 while (x != y){

2 if (x>y) then

3 x=x-y;

4 else

5 y=y-x;

5 }

6 return x;

}

Test cases for branch coverage can be:

{(x=3,y=3),

(x=3,y=2),

(x=4,y=3),

(x=3,y=4)}

White-box Testing: Condition Coverage

Test cases are designed such that:

each component of a composite conditional

expression

given both true and false values.

Consider the conditional expression

((c1.and.c2).or.c3):

Each of c1, c2, and c3 are exercised at least

once, i.e. given true and false values.

It require 2n (the number of component conditions) test cases.

practical only if n is small

White-box testing : Path Coverage Design test cases such that:

all linearly independent paths in the program are

executed at least once.

Defined in terms of control flow graph (CFG) of a program.

A control flow graph (CFG) describes:

the sequence in which different instructions of a

program get executed.

the way control flows through the program.

Drawing a CFG - I Number all the statements of a program.

Numbered statements represent nodes of the

control flow graph.

An edge from one node to another node exists:

if execution of the statement representing the first

node can result in transfer of control to the other

node.

Sequence: 1 a=5;

2 b=a*b-1;

1

2

Drawing a CFG - II Selection:

1. if(a>b) then

2. c=3;

3. else

4. c=5;

5. c=c*c;

Iteration:

1 while(a>b){

2 b=b*a;

3 b=b-1;}

4 c=b+d;

1

2 3

4

1

2

3

4

Example

int f1(int x, int y){

1 while (x != y){

2 if (x>y) then

3 x=x-y;

4 else

5 y=y-x;

5 }

6 return x;

}

1

2

3 4

5

6

Path A path through a program:

a node and edge sequence from the starting node

to a terminal node of the control flow graph.

There may be several terminal nodes for program.

Any path through the program:

introducing at least one new node that is not included in any other independent paths.

McCabe's cyclomatic metric is an upper bound:

for the number of linearly independent paths of a

program

Provides a practical way of determining the maximum number of linearly independent paths in a program.

Cyclomatic Complexity - I Given a control flow graph G, cyclomatic complexity

V(G) = E-N+2

N is the number of nodes in G

E is the number of edges in G

Cyclomatic complexity = 7-6+2 = 3. 1

2

3 4

5

6

Another way of computing cyclomatic complexity: determine number of bounded

areas in the graph

V(G) = Total number of bounded areas + 1

Example: the number of bounded areas is 2.

Cyclomatic complexity = 2+1=3.

Cyclomatic Complexity - II The cyclomatic complexity of a program provides a

lower bound on the number of test cases to be designed

to guarantee coverage of all linearly independent

paths.

does not make it any easier to derive the test cases,

only gives an indication of the minimum number of

test cases required.

Path Testing Draw control flow graph.

Determine V(G).

Determine the set of linearly independent paths.

Prepare test cases:

to force execution along each path.

Number of independent paths: 3

1,6 test case (x=1, y=1)

1,2,3,5,1,6 test case(x=1, y=2)

1,2,4,5,1,6 test case(x=2, y=1)

1

2

3 4

5

6

Cyclomatic Complexity - III Relationship exists between

McCabe's metric & the number of errors existing in

the code,

the time required to find and correct the errors.

also indicates the psychological complexity of a program.

i.e. difficulty level of understanding the program.

Therefore, limit cyclomatic complexity of modules to some reasonable value. (10 or so)

Automated Testing Tools

Mercury Interactive Quick Test Professional: Regression testing WinRunner: UI testing IBM Rational Rational Robot Functional Tester Borland Silk Test Compuware QA Run AutomatedQA TestComplete

Thank You