[go: up one dir, main page]

63% found this document useful (8 votes)
2K views66 pages

ST Lab Manual

The document describes designing black box test cases for an automated banking application. It discusses using boundary value analysis and equivalence class partitioning techniques to generate test cases for different parameters like area code, prefix, suffix, password and commands.

Uploaded by

ShalemRaj
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
63% found this document useful (8 votes)
2K views66 pages

ST Lab Manual

The document describes designing black box test cases for an automated banking application. It discusses using boundary value analysis and equivalence class partitioning techniques to generate test cases for different parameters like area code, prefix, suffix, password and commands.

Uploaded by

ShalemRaj
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 66

1

S.No

LIST OF EXPERIMENTS
Consider an automated banking application. The user can dial the bank from a personal computer, provide a sixdigit Password and follow with a series of keyword commands that activate the banking function. The software
for the application accepts data in the following form:
Area Code
Blank or three-digit number
Prefix
Three-digit number, not beginning with 0 or 1
Suffix
Four-digit number
Password
Six-character alphanumeric
Commands
"Check status", "Deposit", "Withdrawal"
Design adhoc test cases to test the system
Design the test cases to test the above application using the following Black Box testing techniques:
BVA, Worst BVA, Robust BVA, Robust Worst BVA, Equivalence class testing

Page No

11

Consider an application that is required to validate a number according to the following simple rules:
1. A number can start with an optional sign.
2. The optional sign can be followed by any number of digits.
3. The digits can be optionally followed by a decimal point, represented by a period.
4. If there is a decimal point, then there should be two digits after the decimal.
5. Any number-whether or not it has a decimal point, should be terminated a blank.
6. A number can start with an optional sign.
7. The optional sign can be followed by any number of digits.
8. The digits can be optionally followed by a decimal point, represented by a period.
9. If there is a decimal point, then there should be two digits after the decimal.
10. Any number-whether or not it has a decimal point, should be terminated a blank. Generate test cases to test
valid and invalid numbers.
Generate test cases using Black box testing technique to Calculate Standard Deduction on
Taxable Income. The standard deduction is higher for tax payers who are 65 or older or blind. Use the method
given below to calculate tax.

24

1. The first factor that determines the standard deduction is the filing status. The basic standard deduction for the
various filing status are:
4

Single
$4,750
Married, filing a joint return
$9,500
Married, filing a separate return $7,000
2. If a married couple is filing separate returns and one spouse is not taking standard Deduction, the other spouse
also is not eligible for standard deduction.
3. An additional $1,000 is allowed as standard deduction, if either the filer is 65 yrs or the spouse is 65 yrs or
older
4. An additional $1,000 is allowed as standard deduction, if either the filer is blind or the spouse is blind.
Consider A program segment which calculates the maximum value among three integers.
a) Draw the control flow graph for this program segment
b) Determine the cyclomatic complexity for this program
c) Determine the independent paths.
For a Source code of simple insertion sort implementation using array in ascending order in c programming
language,
a) Draw the program graph for given program segment b) Determine the DD path graph
c) Determine the independent paths
d) Generate the test cases for each independent path
Consider a system having an FSM for a stack having the following states and transitions:
States

Initial: Before creation

Empty: Number of elements = 0

Holding: Number of elements > 0, but less than the maximum capacity

Full: Number elements = maximum

Final: After destruction

III Year II Sem

Software Testing Lab

30

36

41

WISE

10

11

12

Initial to Empty: Create


Empty to Holding, Empty to Full, Holding to Holding, Holding to Full: Add
Empty to Final, Full to Final, Holding to Final: Destroy
Holding to Empty, Full to Holding, Full to Empty: Delete
Design test cases for this FSM using state table-based testing.

For a given fragment of program code, calculate the number of tests required for 100% decision coverage? Also
write the test cases.

44

Given the following code, how much minimum number of test cases is required for full statement and branch
coverage?

48

read p read q
if p+q> 100
then print "Large" endif
if p > 50
then print "p Large" endif
Consider a program to input two numbers and print them in ascending order given below. Find all du paths and
Identify those du-paths that are not feasible. Also find all dc paths and generate the test cases for all paths (dc
paths and non dc paths).

55

Consider the above program and generate possible program slices for all variables. Design at least one test case
from every slice.

57

Consider the code to arrange the numbers in ascending order. Generate the test cases for relational coverage, loop
coverage and path testing. Check the adequacy of the test cases through mutation testing and also compute the
mutation score

60

for each.
i = 0;
n=4; //N-Number of nodes present in the graph
While (i<n-1) do j = i + 1;
While (j<n) do
if A[i]<A[j] then swap (A[i], A[j]); end do;
i=i+1;
end do

III Year II Sem

Software Testing Lab

WISE

Exp No-1:PROBLEM STATEMENT:Consider an automated banking application. The user can dail the bank from a personal
computer, provide a six digit password and follow with a series of keyword commands that
activate the banking function the software for the application accepts data in the following form.
Area code

Blank or three digit number

prefix

Three digit number, not beginning with 0 or 1

suffix

Four digit number

password

Six character alphanumeric

Commands

check status,deposit,withdraw

Design adhoc tests to test the system


AIM:-To design an automated banking application by using adhoc testing.
DESCRIPTION:-The testing with no proper test cases and planning is known as adhoc
testing. It is generally performed at the end of the project completion before submission. Here
were are performing a type of adhoc testing called pair testing where there are two teaters as a
pair while one is writing test cases , other will be performing the test.
TEST CASE SCENARIO 1:AREA CODE:-Blank or three digit number
TEST CASE1:
INPUT

EXPECTED OUTPUT

111

accepted

ANALYSIS:-No defects . Test case 1 can be resolved.

III Year II Sem

Software Testing Lab

WISE

TEST CASE2:
INPUT

EXPECTED OUTPUT

abc

accepted

ANALYSIS:-defects found
TEST CASE3:
INPUT

EXPECTED OUTPUT

Ab1

not accepted

ANALYSIS:-no defects .test case3 can be closed


TEST CASE SCENARIO 2:Prefix:-three digit number, not beginning with 0 or 1
TEST CASE1:
INPUT

EXPECTED OUTPUT
Ab1

Not accepted

ANALYSIS:- No defects . Test case 1 can be resolved.

III Year II Sem

Software Testing Lab

WISE

TEST CASE2:
INPUT

EXPECTED OUTPUT

231

accepted

ANALYSIS:- No defects . Test case 2 can be resolved.


TEST CASE1:
INPUT

EXPECTED OUTPUT

40a

accepted

ANALYSIS:- defects found . Test case 3 can not be resolved.

TEST CASE SCENARIO 3:Suffix:-four digit number


TEST CASE1:
INPUT

III Year II Sem

EXPECTED OUTPUT

Software Testing Lab

WISE

9489

accepted

ANALYSIS:- No defects . Test case 1 can be resolved.


TEST CASE2:
INPUT

EXPECTED OUTPUT

12ab

accepted

ANALYSIS:- defects found. Test case 2 can not be resolved.


TEST CASE3:
INPUT

EXPECTED OUTPUT

abc

Not accepted

ANALYSIS:- No defects . Test case 3 can be resolved.


TEST CASE SCENARIO 4:Password:-six character alphanumeric
TEST CASE1:
INPUT

III Year II Sem

EXPECTED OUTPUT

Software Testing Lab

WISE

1@bcd1

accepted

ANALYSIS:- defects found . Test case 1 can not be resolved.

TEST CASE2:
INPUT

EXPECTED OUTPUT

12345a

accepted

ANALYSIS:- No defects . Test case 2 can be resolved.


TEST CASE3:
INPUT

EXPECTED OUTPUT

123456

accepted

ANALYSIS:- defects found . Test case 3 can not be resolved.


TEST CASE SCENARIO 5:Check status:
Rule1:-transactions shown should be 10 of previous performed transactions (mini satements)

III Year II Sem

Software Testing Lab

WISE

TEST CASE1:
INPUT

EXPECTED OUTPUT

mini statement card

last 10 transaction

ANALYSIS:- No defects . Test case 1 can be resolved.


TEST CASE2:
INPUT

EXPECTED OUTPUT

Mini statement card

Last 12 transactions

ANALYSIS:- defects found . Test case 2 can not be resolved.


Deposit:-for a normal undergraduate account, max deposit is 50000/- and min deposit is 1000/TEST CASE1:
INPUT

EXPECTED OUTPUT

Deposit 80,000

accepted

ANALYSIS:- defects found . Test case 1 can not be resolved.


TEST CASE2:

III Year II Sem

Software Testing Lab

WISE

INPUT

EXPECTED OUTPUT

Deposit 20,000

accepted

ANALYSIS:- No defects . Test case 2 can be resolved.

Withdraw:-minimum amount in the account should be 100 and max withdraw should not
exceed 5000/- at a time minimum balance present is 10,000/TEST CASE1:
INPUT

EXPECTED OUTPUT

Draw 6000

Not accepted

ANALYSIS:- No defects . Test case 1 can be resolved.


TEST CASE2:
INPUT

EXPECTED OUTPUT

Draw 4000

accepted

ANALYSIS:- No defects . Test case 2 can be resolved.

III Year II Sem

Software Testing Lab

WISE

10

III Year II Sem

Software Testing Lab

WISE

11

Exp No-2:Consider an automated banking application the user can dial the bank form a personal computer
provide a six digits password and follows with a series of keyword command that activated the
banking application accept data in the following them:
Area code
Blank of three digits number
Prefix
Three digits number not beginning with 0(or)1
Suffix
Four digits number
Password
Six character alphanumeric
Commands
Checkpoint Deposit Withdrawal
AIM: To design a Black box testing for the banking application
Description:
In black box testing there are two cases
1. Boundary value analysis:
In boundary value analysis we can check the tests at the boundary values it mean that
upper limit and lower limit and surrounding the boundary values along with middle values
2. Equivalence class partitioning:
In equivalence class partitioning we cannot check the all the combination of inputs we
divide the entire class of inputs into true class and false class
Boundary Value Analysis:
Area Code: Blank or 3-Digit Number
Minimum input value: Blank
Maximum input value: 3-digit number
Test Data:
min
max
Min+1
Min-1
Max+1
Max-1
Min+ Max/2

III Year II Sem

0
123
1
1234
12
23

Software Testing Lab

WISE

12

Test Case Scenario1:


Testcase1:
Input
1234
0
12

Expected Output
rejected
rejected
rejected

Analysis: No defects in the test case .So test case will be closed.
Testcase2:
Input
123
124

Expected Output
Accepted
Accepted
Accepted

Analysis : No defects in the test case. So test case will be closed.


Testcase3:
Input
123
1245

Expected Output
rejected
rejected
Accepted

Analysis: Defects in the test case. So test case will be closed.

Prefix: 3-digit number not beginning with 0 or 1


Minimum input value: 3-digit number
Maximum input value: 3-digit number
Test Data:
min
max
Min+1

III Year II Sem

234
034
2345

Software Testing Lab

WISE

13

Min-1
Max+1
Max-1
Min + Max/2

23
345
03
345

Test Case Scenario2:


Testcase1:
Input
034
0345
2345

Expected Output
rejected
rejected
rejected

Analysis : No defects in the test case. So test case will be closed.


Testcase2:
Input
123
345
124

Expected Output
Accepted
Accepted
Accepted

Analysis: No defects in the test case. So test case will be closed.


Testcase3:
Input
123
345
12456

Expected Output
rejected
rejected
Accepted

Analysis: Defects in the test case. So test case will be closed.


Suffix: 4-digit number
Minimum input value: 4-digit number
Maximum input value: 4-digit number
Test Data:
min
max

III Year II Sem

1111
1142

Software Testing Lab

WISE

14

Min+1
Min-1
Max+1
Max-1
Min+ Max/2

11115
111
11423
114
1134

Test Case Scenario3:


Testcase1:
Input
111
11423
234aq

Expected Output
rejected
rejected
rejected

Analysis: No defects in the test case. So test case will be closed.


Testcase2:
Input
1231
3454
1245

Expected Output
Accepted
Accepted
Accepted

Analysis: No defects in the test case. So test case will be closed.


Testcase3:
Input
1231
3451
12456

Expected Output
rejected
rejected
Accepted

Analysis: Defects in the test case. So test case will be closed.


Password:6-Character Alpha Numeric
Test Data:
min
max
Min+1

III Year II Sem

Abcd12
1142ab
Abcd123

Software Testing Lab

WISE

15

Min-1
Max+1
Max-1
Min+ Max/2

Abcd1
1142abc
1142a
Abc123

Test Case Scenario4:


Testcase1:
Input
Abcd1
Abcd123
Abcdef

Expected Output
rejected
rejected
rejected

Analysis: No defects in the test case. So test case will be closed.


Testcase2:
Input
Abc132
1142ab
1a2b3c

Expected Output
Accepted
Accepted
Accepted

Analysis: No defects in the test case. So test case will be closed.


Testcase3:
Input
123abc
34abcd
124563

Expected Output
rejected
rejected
Accepted

Analysis: Defects in the test case. So test case will be closed.


Test case scenario: 5
Command: check status, deposit ,with drawl
Check status:

III Year II Sem

Software Testing Lab

WISE

16

Test case data: minimum and maximum inputs values 4


Min
Max
Min+1
Max+1
Min-1
Max-1
Min+ max/2

1124
2341
11241
12341
112
234
1124

Test case 1:
Input
1124
2341

Expected output
Accepted
Accepted

Analysis: No defects in this test case so we can close the test case
Test case2:
Input
12341
11241

Expected output
Rejected
Rejected

Analysis: No defects in this test case so we can close the test case
Test case for deposit: minimum and maximum inputs are as follows
Test case data:
Min=10,000
Max=40,000
Min
Max
Min+1
Max+1
Min-1
Max-1
Min+ max/2

III Year II Sem

1124
2341
11241
12341
112
234
1124

Software Testing Lab

WISE

17

Test case 1:
Input
10,000
40,000

Expected output
Accepted
Accepted

Analysis: No defects in this test case so we can close the test case

Test case2:
Input
999
39,999

Expected output
Rejected
Rejected

Analysis: No defects in this test case so we can close the test case
Test case for withdrawl: minimum and maximum inputs are as follows
Test case data: Account Balance 1000
Min=100
Max=500
Min
Max
Min+1
Max+1
Min-1
Max-1
Min+ max/2

100
501
1001
499
999
775

Input
500
100

Expected output
Accepted
Accepted

500

Test case 1:

III Year II Sem

Software Testing Lab

WISE

18

Analysis: No defects in this test case so we can close the test case
Test case2:
Input
999
39,999

Expected output
Rejected
Rejected

Analysis: No defects in this test case so we can close the test case

Equivalence class partioning:


Area code: Blank or 3digit number
true class
411
423
963
823

False class
4112
Abcd
1239
-

Test case 1:
Input

Expected outcome

411
Analysis: no defect in the test case so it can be closed

accepted

Test case 2:
Input
1239
Analysis: no defect in the text case it can be close

Expected outcome
Reject

Prefix: thee digit number not begining with 0 and 1


True class
421
420
425

III Year II Sem

False class
011
101
1234

Software Testing Lab

WISE

19

427

1111

Test case 1:
Input

Expected outcome

421
accepted
Analysis: no defect in this close so we can close it
Test case 2:
Input
Expected outcome
01234
reject
Analysis: no defect in this close so we can close it

Suffix: four digit number


True class
1298
1234
1456
1500

False class
12ab
Abcd
121cde
14abc

Test case 1:
Input
1298

Expected outcome
Accepted

Analysis: no defect in the test case so we can close it


Test case 2:
Input
12ab

Expected outcome
Reject

Analysis: no defect in this test case so we can close it


Test case 3:

III Year II Sem

Software Testing Lab

WISE

20

Input
1rbace

Expected outcome
Reject

Analysis: no defect in this test case so we can close it


Password: six character alpha numeric
True class
123abc
Abc456
78910c
Irab

False class
Abcde
123456
000000
111111

Test case 1:
Input
123abc

Expected outcome
Accept

Analysis: no defect in this test case so we can close it


Test case 2:
Input
000000

Expected outcome
Reject

Analysis: no defect in this test case so we can close it


Test case 3:
Input
112233311

Expected outcome
Reject

Analysis: no defect in this test case so we can close it


Command: check sum, deposit, with drawl

III Year II Sem

Software Testing Lab

WISE

21

Test data for check status


Minimum and maximum input value=four digit pin number
True class
1111
1234
8225
6725
9989
8924

False class
01
123
1
@456
12345

Input
1234
123

Expected outcome
Accepted
Accepted

Test scenario :
Test case 1:

Analysis: no defect in this test case so we can close it


Test case 2:
Input
-

Expected outcome
Not Accepted

Analysis: defects were found in this test case so we check it


Test data for deposit:
Minimum input values =1000
Maximum input values=50,000
True class
1000
1001
1100
50000
50002
4400

III Year II Sem

False class
100
999
678
50100
60000
-

Software Testing Lab

WISE

22

Test case scenario:


Deposit: for a normal under graduate account , max deposit is 50000 and maximum deposit is
1000
Test case 1:
Input
Expected outcome
1000
Accept
Analysis: no defect in this test case so we can close it
Input
10

Expected outcome
Not Accepted
Not accepted

Testcase2:
Analysis: no defect in this test case so we can close it

III Year II Sem

Software Testing Lab

WISE

23

Test case 3:
Input

Expected outcome

60000
10

Accepted
accepted

Analysis: defects were found in it hence we cannot close it

Test case for with drawl:


Minimum input value=100
Maximum input value=5000
True class
100
101
110
200
250
4000
1000

False class
10
6000
10000
51700
99
90000

Test case scenario:


With drawl: minimum amount in the account should be 100
Maximum with drawl should not exceed 5000 at a time minimum balance present is 10000
Test case 1:
input
100

Expected outcome
Accept

Analysis: no defect in this test case so we can close it


Test case 2:
Input

III Year II Sem

Expected outcome

Software Testing Lab

WISE

24

Not Accepted

Analysis: no defect in this test case so we can close it


Test case 3:
Input
9000
Analysis: defects were found

III Year II Sem

Expected outcome
Accepted

Software Testing Lab

WISE

25

Exp No-4:Generate test case using black box testing technique to calculate standard deduction on taxable
income. The standard deduction is higher for tax payers who are 65 or older or blind use the
method given below to calculate maximum.
1. The first factor that determines the standard deduction is filling status the basic standard
deduction the various filling standards are:

single
$4,750
Married filing or join $9500
return
Married filing or join $7000
return
2. If a married couple is filing separate returns and one spouse is not taking standard deduction.
The other spouse also is not elgible for standard deduction.
3. An additional $1000 is allowed as standard deduction, if either the file is 65years or the spouse
is 65years or older (the latter case applicable when the filing status is married and filing joint).
4. An additional $1000 is allowed is standard deduction, if either the filter is blind or the spouse
is blind (the latter case applicable when the filing status is married and filing joint).

Aim: to calculate standard deduction for tax payers by using black box testing.
Description:
Black box testing is a method of software testing that examines the functionality of an
application without peering into its internal structures or workings. This method of can be
applied to virtually every level of software testing unit, integration, system and acceptance.
Test case scenarios:
Age: higher for tax payers ,who are 65 or older or blind.
Min=max
Min-1
Max+1

III Year II Sem

65
65-1=64
65+1=66

Software Testing Lab

WISE

26

blind
Min=max
Min-1
Max+1
Input
Blind

4750
4750-1=4749
4750+1=4751

Test case 1:

Expected outcome
accepted

Analysis: no defect test case1 can be closed


Test case 2:
Input
Expected out come
65
accepted
Analysis: no defect test case2 can be closed
Single: $47, 50 Test case 3:
Input

Expected outcome

60
rejected
Analysis: No defect test case2 can be closed
Test case 1:
Input
$4750

Expected outcome
accepted

Analysis: No defect test case1 can be closed


Test case 2:
Input

Expected outcome

$4749

rejected

Analysis: No defect test case 2 can be closed


Test case 3:
Input
$4753

III Year II Sem

Expected outcome
rejected

Software Testing Lab

WISE

27

Analysis: No defect test case 3 can be closed

Join-Return: $9500
Test case 1:
Input
$9500

Expected outcome
accepted

Analysis: No defect test case 1 can be closed


Test case 2:
Input
$9599

Expected outcome
rejected

Analysis: No defect test case 2 can be closed


Test case 3:
Input
$523

Expected outcome
rejected

Analysis: No defect test case 3 can be closed


Join return: $7000
Test case 1:
Input
$7000

Expected outcome
accepted

Analysis: No defect test case 1 can be closed


Test case 2:
Input
$7023

III Year II Sem

Expected outcome
rejected

Software Testing Lab

WISE

28

Analysis: No defect test case 2 can be closed


Test case 3:
Input
$7001

Expected outcome
rejected

Analysis: No defect test case 3 can be closed


Rule 2: if one spouse is not taking standard deduction also not eligible.
Min=max
Min

Both
one

Test case 1:
Input
both

Expected outcome
accepted

Analysis: No defect test case1 is closed


Test case 2:
Input
Spouse one(wife)

Expected outcome
rejected

Analysis: no defect test case 2 is closed.


Test case 3:
Input
Spouse one (men)

Expected outcome
rejected

Analysis: no defect test case 3 is closed.


Rule 3: $1000 is allowed if either file is 65 or spouse is 65 years or older.
Min=max

III Year II Sem

65

Software Testing Lab

WISE

29

Max+1
Min-1

65+1=66
65-1=64

Test case 1:
Input
70

Expected outcome
accepted

Analysis: no defect test case 1 is closed


Test case 2:
Input
Spouse once age
is 60

Expected outcome
rejected

Analysis: no defect test case 2 is closed


Test case 3:
Input
Both aged 63

Expected outcome
rejected

Analysis: no defect test case 3 is closed


Rule 4: $1000 if allowed if either the filter is blind or the spouse is blind.
Min=max
Min-1

2
2-1=1

Test case 1:
Input
Both blind

Expected outcome
accepted

Analysis: no defect test case 1 is closed


Test case 2:
Input
Filter is blind

III Year II Sem

Expected outcome
accepted

Software Testing Lab

WISE

30

Analysis: no defect test case 2 is closed.


Test case 3:
Input
Both are not
blind

Expected outcome
rejected

Analysis: no defect test case 3 is closed.

Viva questions:
1. What is black box testing?

III Year II Sem

Software Testing Lab

WISE

31

Exp No-5:Consider following program segment


1. int max(int i,int j, int k)
2. {
3. int max
4. if(i>j)then
5. if(i>k)then max=i;
6. else max=k;
7. else if(j>k) max=j
8. else max=k
9. return(max);
10. }
a. Draw the control flow graph for this program segment
b. Determine the cyclomatic complexity for this program
c. Determine the independent path.
AIM:
To draw the control flow graph to calculate the cyclomatic complexity and independent
path for given problem.

III Year II Sem

Software Testing Lab

WISE

32

DESCRIPTION:
sequence

selection

iteration

1. x=5

1. if x<y

1. x=0

2.y=x*x

2. x=x+y

2. while(count>0)

3. else x=x*y;

3. x=x+5

4. printf("%d",x);

count=count-1

a1

4. printf("%d",x);
1

4
2

Control flow graph:


A control flow graph represents the execution path with in a program code. It covers
selective, iterative, sequence statements in a given code.

III Year II Sem

Software Testing Lab

WISE

33

III Year II Sem

Software Testing Lab

WISE

34

Cyclomatic complexity:
It is a metric used for measuring the complexity of a given program code with respect to
dependent and independent paths in a control flow graph (coupling and cohesion). It can be
calculate in three ways:
1. The total number of predictive node is equal to the cyclomatic complexity of the program.
2. The total number of independent paths equal the cyclomatic complexity.
3. By calculating the total number of nodes and edges in the control flow graph using formula:
no. of edges-no. of nodes+2(E-N+2)
Independent path:
Independent path through the program it introduces at least one new edge that is not
included in any other path before it.
p1:1->2->3->8->9
p2:1->2->3->4->5->6->7->9
p3:1->2->3->4->5->6->5->9

Program:
a. control flow graph
1

III Year II Sem

Software Testing Lab

WISE

35

3
4
5

10
b. cyclomatic complexity:
Here, N=10 and E=12
E-N+2
=12-10+2
=2+2
=4
c. independent paths:
path1:1->2->3->4->5->9
path2:1->2->3->4->5->6->9
path3:1->2->3->4->7->8->9
path4:1->2->3->4->5->7->8->9

III Year II Sem

Software Testing Lab

WISE

36

Viva Questions:
1) What is cyclomatic complexity?
2) What is an independent path?
3) What is control flow graph?
4) What are the loops?
5) Difference between the independent path and dependenth path.

III Year II Sem

Software Testing Lab

WISE

37

Exp No-6:Aim: Source code of simple insertion sort implementation using array in ascending order in c
programming language.
Description:
#include<stdio.h>
int main ()
{
int i, j, s, temp, a [20];
Printf (enter total elements :);
Scanf (%d, &s);
Printf (enter %d elements: s);
for (i=0; i<s; i++)
Scanf (%d, &a[i]);
for (i=1; i<s; i++)
Temp=a[i];
j=i-1;
While ((temp<a[j]) && (j>=0))
{
a [j+1] =a[j];
j=j-1;

III Year II Sem

Software Testing Lab

WISE

38

}
a [j+1] =temp;
}
Printf (after sorting);
For (i=0; i<s; i++)
Printf (%d, a[i]);
Return o;
}
Test scenario:
a)
b)
c)
d)

Draw the program graph for given program segment.


Determine the DD path graph.
1
Determine the independent paths.
Generate the test cases for each, independent path.
2

a) Draw the program graph for given program segment.


3

Selection statements

4
5
6
7
for

for

9
100100
111
12

III Year II Sem

Software Testing Lab

WISE

39

for

13

while

141
151

161
171
181
191
20

21

22
for
23
24

25

III Year II Sem

Software Testing Lab

WISE

40

b) Determine the DD path graph.


A decision-to-decision path, or DD path, is a path of execution between two
decisions.
More recent versions of the concept also include the decisions themselves in their
own DD paths.
Rules:
1) Single node with in deg=0.
2) Single node without deg=0.
3) Single node with in deg>=2 or out deg>=2;
4) Single node in deg=1 out deg=1.
5) Maximal chain of length>=1.
c) Determine the independent paths.
1

18

Cyclometric Complexity E=24, n=25


24-25+2=-1+2=1

d) Generate the test cases for each, independent path.

For (i=0; j<=5; i++)

Test case1:
Input
i=1

Output
True

Test case2:
Input
i=6

III Year II Sem

Output
True

Software Testing Lab

WISE

41

Input
i=0

Analysis: Test case is failed.

Output
True

10

11

12

13

for (i=1; i<=5; i++)


Test case1:

Analysis: Test case is failed.

Test case2:
Input
i=6

Output
False

Analysis: Test case is successful.

VIVA QUESTIONS:
1) What is Sorting?
2) What is DD path?
3) What is Independent path?

III Year II Sem

Software Testing Lab

WISE

14 15

42

Exp No-7:Consider a system having FSM for a stack having the following states and transactions
States:
Initial: before creation
Empty: no of elements=0
Holding, no of elements>0, but<the max capacity
Full: no of elements =maximum
Final: after destruction
Initial to empty: create
Empty to holding, empty to full, holding to holding to full: Add
Empty to final, full to final, holding to final: destroy
Holding to empty, full to holding full to empty
Delete
AIM: To write a test case for a system having FSM for a stack
DESCRIPTION: FSM is a mathematical model of computation used to design both computer
programs and sequential logic circuits. A particular FSM is defined by list of its states, and the
triggering condition for each transition behavior of state machines can be observed in many
devices.
Test case: 1
Condition:
Initial: before creation
Analysis: Test case is successful before creation
Condition: Empty no of elements =0
Test case: 1

III Year II Sem

Software Testing Lab

WISE

43

Elements=0

true

Analysis: Test case successful


Condition: Holding no of elements >0, but <the max capacity
Capacity=3
Test case: 1
Elements=0

false

Analysis: Test case successful


Test case: 2
Elements=4

true (locked)

Analysis: test case failed


Condition:
Full no of elements = maximum
Test case: 1

maximum=3

Elements=3

True (unlocked)

Analysis: test case is successful


Condition: After destruction
Analysis: test case successful after destruction
Transaction:

coin
push

Locked

initial

Unlocked

coin

pus
h

Condition: add
Test case: 1

III Year II Sem

Software Testing Lab

WISE

44

Elements: 3

unlocked

Analysis: Test case successful


Test case: 2
Elements: 2

unlocked

Analysis: test case failed


Test case: 3
Elements: 4

locked

Analysis: test case successful


Test case: 4
Elements: 3

locked

Analysis: test case failed


Condition:

Initial
add
Holding

Empty
delete

add

delete

delete

delete

destroy

Final

Full
destroy

III Year II Sem

Software Testing Lab

WISE

45

III Year II Sem

Software Testing Lab

WISE

46

Exp No-8:AIM:
Given the following fragment of code. How many tests are required for 100% decision
coverage? Give the test cases
If width > length
Then biggest_dimension=width
If height > width then
Biggest_dimension=height
End-if
Else if biggest_dimension=length then
If height > width
Then biggest_dimension=height
End-if
End-if
End-if
Code segment:
If(width>length)
{
Biggest_dimension=width;
If(height>width)
{
Biggest_dimension=height;
}
}

III Year II Sem

Software Testing Lab

WISE

47

Else if (dimension=length)
{
If(height>length)
Biggest_dimension=height
}
}
Aim:to generate the test cases for 100% decision coverage
Description: to every decision condition should be in test cases is called 100% decision
coverage.
Condition:

width > height

Assume width=10 height=3 length=6


Testcase1:
input
10>6

output
true

Analysis: test case succeeded


Condition:

biggest_dimension=width=10
height > width

testcase1:
input
3>10

Output
False

Analysis: test case succeeded


Width=10 Height=15 Length=6
Condition:

width > length

Testcase1:

III Year II Sem

Software Testing Lab

WISE

48

input
10>6

output
true

Analysis: test case succeeded


biggest_dimension=width=10
Condition:

height>width

Testcase1:
input
15>10

output
true

Analysis: test case succeeded


biggest_dimension=height=15
Condition:

width>length

Testcase1:
input
10>6

output
true

Analysis: test case succeeded


biggest_dimension=width=10
Testcase1:
input
15>16

output
true

input
10>11

output
true

Analysis: test case is failed


Condition:

width>length

Testcase1:

III Year II Sem

Software Testing Lab

WISE

49

Analysis: test case is failed


Dimension=length
Testcase1:
input
6=6

output
true

Analysis: test case is succeeded


Height>length
Testcase1:
input
15>6

output
true

Analysis: test case is succeeded


Flowchart:

Width>height

true

Width>length

false

Dimension=lengt
h

false
true
fals

III Year II Sem

Biggest_dimension=
height

Height>length

Software Testing Lab

false

WISE

50

Exp No-9:Aim:
Give the following code,how much minimum number of test cases required for full statement
and
branch
Out
of coverage.
loop

Read pread 2

Biggest_dimension=h
eight

If p+q>100

Out of loop

Then print large


End if
If p>50
Then print plarge
#include<stdio.h>
{
Int p,q;
Printf(enter p:);
Scanf(%d,&p);
Printf(enter q:);
Scanf(%d,&q);
If(p+q>100)
{
Printf(large);
}
Else
{
Printf(small);

III Year II Sem

Software Testing Lab

WISE

51

}
If(p>50)
{
Printf(plarge);
Else
{
Printf(psmall);
}
}
Description:
The statement coverage also known as line coverage or segment coverage.The statement
coverage along the true conditions.Through statement coverage we can identify the statements
executed and where the code is not executed because of blockage.In this process each and every
line of code needs to be closed and executed.
Branch testing:
It is a testing method which aims to ensure that each one of the possible branch from each
decision point executed atleast once and there by ensuring that all reachable code executed.
That is every branch taken each lay true and false.it helps in validating all the branches in
the code making sure that no branch leads to abnormal behavior of the application.

III Year II Sem

Software Testing Lab

WISE

52

Control flow graph:


1

Read p,q
p

2
Print p+q large

5
P is large
6

13
13

10

14
14
15

11
1

16
16
18
18

22
22

24
III Year II
Sem
24

Software Testing Lab

WISE

53

Test-cases:
Condition:#include<stdio.h>(header file)
Test case:1
Input

Expected outcome

#include<stdio.h>

false

Analysis: Test case failed


Test case:2
Input

Expected outcome

#include<stdio.h>

Accepted

Analysis: Test case failed


Test case:3
Input
Expected outcome
#include<stdio.h>
Accepted
Analysis: Test case excuted successfully
Condition:
Int p;
Test case:1
Input
Expected outcome
Int p;
Accepted
Analysis: Test case excuted successfully
Test case:2
Input
Expected outcome
Float p;
Accepted
Analysis: Test case rejected
Test case:3
Input

III Year II Sem

Expected outcome

Software Testing Lab

WISE

54

Float p;
Rejected
Analysis: Test case executed successfully
Condition:
Int q;
Test case:1
Input
Expected outcome
Int q;
Accepted
Analysis: Test case executed successfully
Test case:2
Input
Expected outcome
Char q;
Rejected
Analysis: Test case executed successfully
Condition:
P+q>100;
Test case:1
Input
Expected outcome
P+q>100
Accepted
Analysis: Test case executed successfully
Test case:2
Input
Expected outcome
P+q=100
Rejected
Analysis: Test case executed successfully

III Year II Sem

Software Testing Lab

WISE

55

Test case:3
Input
P+q<100
Analysis: Test case failed

Expected outcome
Accepted

Test case:4
Input
Expected outcome
P+q<100
Rejected
Analysis: Test case executed successfully
Condition:
Else
Test case:1
Input
Expected outcome
p&q are big
Accepted
Analysis: Test case failed
Test case:2
Input

Expected outcome

p&q are big

Accepted

Analysis: Test case executed successfully


Test case:3
Input
Expected outcome
p&q are big
Rejected
Analysis: Test case executed successfully
Condition:
p>50;

Test case:1
Input

III Year II Sem

Expected outcome

Software Testing Lab

WISE

56

p>50
Accepted
Analysis: Test case executed successfully
Test case:2
Input
p>50

Expected outcome
Rejected

Analysis: Test case failed


Test case:3
Input
Expected outcome
P=50
Rejected
Analysis: Test case executed successfully
Test case:4
Input

Expected outcome

p<50

Accepted

Analysis: Test case failed


Condition:
Else
Test case:1
Input

Expected outcome

psmall

Accepted

Analysis :Test case executed successful


Test case:2
Input
Expected outcome
plarge
Accepted
Analysis: Test case failed
Test cae:3
Input

Expected outcome

plarge

Rejected

III Year II Sem

Software Testing Lab

WISE

57

Analysis: Test casr executed successfully

III Year II Sem

Software Testing Lab

WISE

58

Exp No-10:Aim:
To identify and write the test cases for all du-paths and dc-paths for a given program.
Description:
Calculation of du-paths and dc-paths comes under "Data Flow Testing", where the focus is
mainly laid on variables. We use variables in a program for
1) Receiving Values
2) Referencing in Calculations
3) Setting other variables.
du-path calculation:
A "definition-use(du)path" in a graph is a path in PATHS(P) such that for some v in V, there
exists DEF(v, m), USE( v, n) nodes where m, n are the initial and final nodes respectively.
dc-path calculation:
A "definition-clear(dc)path" w.r.t. a variable 'v' in a graph is a du-path in PATHS(P) where
the initial node of the path is the only defining node of v in the path.

III Year II Sem

Software Testing Lab

WISE

59

Write test cases for


1) a<b both true and false conditions
2) a>b both true and false conditions
3) a=b both true and false conditions

III Year II Sem

Software Testing Lab

WISE

60

Exp No-11:Aim:
To identify and write at least one test case for every program slice for a given program.
Description:
Program Slicing:
In computer programming, program slicing is the computation of the set of programs
statements, the program slice, that may affect the values at some point of interest, referred to
as a slicing criterion. Program slicing can be used in debugging to locate source of errors more
easily. Other applications of slicing include software maintenance, optimization, program
analysis, and information flow control.
At first, slicing was only static, i.e., applied on the source code with no other information than
the source code. Bogdan Korel and Janusz Laski introduced dynamic slicing, which works on
a specific execution of the program (for a given execution trace). Other forms of slicing exist,
for instance path slicing.
Unlike dc and du paths in Data Flow Testing, " Program Slicing" or "Slice Based Testing" is
also efficient in removing data flow anamolies for the given program.
Let us consider a program, P for a program graph, G(P) for a given set of variables, V. Then
slice of V at statement n - S(V, n). Here, we exclude all non-executable statements.
Slices are used in finding
1) Slice Composition
2) Relative complement of slices.
Slicing is categorized into
a) Static Slicing:
Based on the original definition of Weiser, informally, a static program slice S consists of all
statements in program P that may affect the value of variable v at some point p. The slice is
defined for a slicing criterion C=(x,V), where x is a statement in program P and V is a subset
of variables in P. A static slice includes all the statements that affect variable v for a set of all
possible inputs at the point of interest (i.e., at the statement x). Static slices are computed by
finding consecutive sets of indirectly relevant statements, according to data and control

III Year II Sem

Software Testing Lab

WISE

61

dependencies.
Example: Consider the following program segment
int i;
int sum = 0;
int product = 1;
for(i = 1; i < N; ++i) {
sum = sum + i;
product = product * i;
}
write(sum);
write(product);
This new program is a valid slicing of the above program with respect to the criterion ( write
(sum) ,{sum}):
int i;
int sum = 0;
for(i = 1; i < N; ++i) {
sum = sum + i;
}
write(sum);
b) Dynamic Slicing:
Makes use of information about a particular execution of a program. A dynamic slice contains
all statements that actually affect the value of a variable at a program point for a particular
execution of the program rather than all statements that may have affected the value of a
variable at a program point for any arbitrary execution of the program.
An example to clarify the difference between static and dynamic slicing. Consider a small
piece of a program unit, in which there is an iteration block containing an if-else block. There
are a few statements in both the if and else blocks that have an effect on a variable. In the case
of static slicing, since the whole program unit is looked at irrespective of a particular
execution of the program, the affected statements in both blocks would be included in the
slice.
But, in the case of dynamic slicing we consider a particular execution of the program, wherein
the if block gets executed and the affected statements in the else block do not get executed. So,
that is why in this particular execution case, the dynamic slice would contain only the

III Year II Sem

Software Testing Lab

WISE

62

statements in the if block.


Consider the program segment:

#include<stdio.h>
#include<conio.h>
1. void main ()
2. {
3 int a, b, t;
4. Clrscr ();
5. Printf (Enter first number);
6. scanf (%d,&a);
7. printf(Enter second number);
8. scanf(%d,&b);
9. if (a<b){
10. t=a;
11. a=b;
12. b=t;
13. }
14. printf (%d %d, a, b);
15 getch ();
}
Test Cases for variables:
1) Variable 'a':
a) Successful reading of variable a
b) Unsuccessful reading of variable a(Memory problem)
2) Variable 'b':
a) Successful reading of variable b
b) Unsuccessful reading of variable b (incorrect format)
3) Variablet:
a) Successful reading of variable t
b) Unsuccessful reading of variable t(garbage value problem)

III Year II Sem

Software Testing Lab

WISE

63

Exp No-12:Aim:
To identify and write the test cases for relational coverage ,loop coverage and path testing.
Apply Mutuation testing and derive the mutuation score for each test case.
Description:
1) Relational Operator Coverage
This metric reports whether boundary situations occur with relational operators (<, <=, >, >=).
The hypothesis is that boundary test cases find off-by-one mistakes and uses of the wrong
relational operators such as < instead of <=. For example, consider the following C code
fragment:
Eg: if (a < b)
Statement;
Relational operator coverage reports whether the situation a==b occurs. If a==b occurs and the
program behaves correctly, you can assume the relational operator is not suppose to be <=.
2) Loop Coverage
This metric reports whether you executed each loop body zero times, exactly once, and more
than once (consecutively). For do-while loops, loop coverage reports whether you executed the
body exactly once, and more than once.
The valuable aspect of this metric is determining whether while-loops and for-loops execute
more than once, information not reported by other metrics.

III Year II Sem

Software Testing Lab

WISE

64

3) Path Coverage
This metric reports whether each of the possible paths in each function have been followed. A
path is a unique sequence of branches from the function entry to the exit.Also known as
predicate coverage. Predicate coverage views paths as possible combinations of logical
conditions.
Since loops introduce an unbounded number of paths, this metric considers only a limited
number of looping possibilities. A large number of variations of this metric exist to cope with
loops. Boundary-interior path testing considers two possibilities for loops: zero repetitions and
more than zero repetitions. For do-while loops, the two possibilities are one iteration and more
than one iteration.
Path coverage has the advantage of requiring very thorough testing. Path coverage has two
severe disadvantages. The first is that the number of paths is exponential to the number of
branches. For example, a function containing 10 if-statements has 1024 paths to test. Adding just
one more if-statement doubles the count to 2048. The second disadvantage is that many paths are
impossible to exercise due to relationships of data. For example, consider the following C code
fragment:
Eg: if (success)
statement1;
statement2;
If (success)
statement3;
Path coverage considers this fragment to contain 4 paths. In fact, only two are feasible:
success=false and success=true.
4) Mutation Testing:
Mutation testing is a technique that focuses on measuring the adequacy (quality) of test data (or
test cases). Here, we modify a program by introducing a single small change to the code.
Points to remember:

A modified program is called mutant

III Year II Sem

Software Testing Lab

WISE

65

A mutant is said to be killed when the execution of test case cause it to fail. The mutant is
considered to be dead

A mutant is an equivalent to the given program if it always produce the same output as
the original program

A mutant is called killable or stubborn, if the existing set of test cases is insufficient to
kill it

A mutation score for a set of test cases is the percentage of non-equivalent mutants killed
by the test suite

The test suite is said to be mutation-adequate if its mutation score is 100%

Mutation score = 100D/(N E), where


D: is the dead mutants,
N: the total number of mutants,
E: the number of equivalent mutants.

Consider the given program segment:


i = 0;
n=4; //N-Number of nodes
present in the graph While
(i<n-1) do j = i + 1;
While (j<n) do
if A[i]<A[j] then swap
(A[i], A[j]); end do;
i=i+1;
end do
Write any one test case for each of relation coverage, loop coverage, path testing, mutuation
testing and calculate the mutuation score.

III Year II Sem

Software Testing Lab

WISE

66

III Year II Sem

Software Testing Lab

WISE

You might also like