Jawaharlal Nehru Engineering College

Laboratory Manual

SOFTWARE TESTING

For

Third Year Students IT

Dept: Information Technology

10, February 2020 – ISO 9001:2015, 14001:2015 Tech Document

D.K.Budhwant, (A.P, IT)
 Author JNEC, Aurangabad
 FOREWORD

It is my great pleasure to present this laboratory manual for third year

engineering students for the subject of Software Testing keeping in view the
vast coverage required to design algorithms.

As a student, many of you may be wondering with some of the questions in

your mind regarding the subject and exactly what has been tried is to answer
through this manual.

As you may be aware that MGM has already been awarded with ISO
9001:2015 certification and it is our endure to technically equip our students
taking the advantage of the procedural aspects of ISO 9001:2015
Certification.

Faculty members are also advised that covering these aspects in initial stage
itself, will greatly relieved them in future as much of the load will be taken
care by the enthusiasm energies of the students once they are conceptually
clear.

Dr. H.H.Shinde
Principal
 LABORATORY MANUAL CONTENTS

This manual is intended for the Third Year students of Information

Technology in the subject of Software Testing. This manual typically contains
practical/Lab Sessions related to the subject to enhance understanding.

Although, as per the syllabus, study of Software Testing is prescribed, we have

made the efforts to cover various methods of Software Testing covering
different aspects of methods to test programs.

Students are advised to thoroughly go though this manual rather than only
topics mentioned in the syllabus as practical aspects are the key to
understanding and conceptual visualization of theoretical aspects covered in
the books.

Good Luck for your Enjoyable Laboratory Sessions

Vision of the department
To develop expertise of budding technocrats by imparting technical knowledge
and human value based education.

Mission of the department

1. Equipping the students with technical skills, soft skills and professional
attitude.
2. Providing the state of art facilities to the students to excel as competent
professionals, entrepreneurs and researchers.

Program Specific Outcomes

PSO1. An ability to design, develop and implement computer programs in the
areas related to Algorithms, Multimedia, Website Design, System Software,
DBMS and Networking.
PSO2. Develop software systems that would perform tasks related to
Research, Education and Training and/or E governance.
PSO3. Design, develop, test and maintain application software that would
perform tasks related to information management and mobiles by utilizing
new technologies to an individual or organizations.

Program Educational Objectives

PEO1. The graduates will utilize their expertise in IT industry and solve
industry technological problems.
PEO2. Graduates should excel in engineering positions in industry and
other organizations that emphasize design & implementation of IT
applications.
PEO3. Graduates will be innovators & professionals in technology
development, deployment & system implementation.
PEO4. Graduates will be pioneers in engineering, engineering management,
research and higher education.
PEO5. Graduates will be good citizens & cultured human being with full
appreciation of importance of IT professional ethical & social
responsibilities.
Lab Outcomes:
Students will able to:

LO 1: To implement different testing techniques to practical test and

understand their merits and demerits

LO 2: To understand and study one of the software testing tool

DOs and DON’Ts in Laboratory:

1. Make entry in the Log Book as soon as you enter the Laboratory.

2. All the students should sit according to their roll numbers starting from their
left to right.

3. All the students are supposed to enter the terminal number in the log book.

4. Do not change the terminal on which you are working.

5. All the students are expected to get at least the algorithm of the
program/concept to be implemented.

6. Strictly observe the instructions given by the teacher/Lab Instructor.

Instruction for Laboratory Teachers::

1. Submission related to whatever lab work has been completed should be done
during the next lab session. The immediate arrangements for printouts related to
submission on the day of practical assignments.

2. Students should be taught for taking the printouts under the observation of lab
teacher.

3. The promptness of submission should be encouraged by way of marking and

evaluation patterns that will benefit the sincere students.
Lab Experiments List:
1 Study of Manual and Automated Testing.

2 Design, develop, code and run the program in any suitable language to solve the
commission problem. Analyze it from the perspective of data flow testing, derive at least
10 different test cases, execute these test cases and discuss the test results.

3 Design, develop, code and run the program in any suitable language to solve the NextDate
problem. Analyze it from the perspective of decision table-based testing, derive at least
10 different test cases, execute these test cases and discuss the test results.

4 Design, develop, code and run the program in any suitable object-oriented language to
solve the calendar problem. Analyze it from the perspective of OO testing, derive test
cases to test the method that increment the date and the method that increments the
month., execute these test cases and discuss the test results.

5 Design, develop, code and run the program in any suitable object-oriented language to
solve the currency converter problem. Analyze it from the perspective of use case-based
system testing, derive appropriate system test cases, execute these test cases and discuss
the test results.

6 Design, develop, code and run the program in any suitable language to implement an
absolute letter grading procedure, making suitable assumptions. Determine the basis
paths and using them derive different test cases, execute these test cases and discuss the
test results
.
7 Design, develop, code and run the program in any suitable language to implement the
binary search algorithm. Determine the basis paths and using them derive different test
cases, execute these test cases and discuss the test results.
 Experiment 1
Study of Manual and Automated Testing.

1. Testing is a process of executing a program with the intent of finding anerror.

2. A good test case is one that has a high probability of finding an as yet undiscoverederror.
3. A successful test is one that uncovers an as yet undiscoverederror.

Testing of software can be done in both Automation and Manual testing method, but it’s totally
depends on the project requirement, budget associated with the project, and which testing
method will be benefited to the project. This article provides basic information about Manual
Testing and Automation Testing, enjoy reading it and let us know in the comment about which
one is best for your project.

Automation Testing:
The method takes automation tool support to execute the test cases is known as Automation
Testing. Automated testing is good for large project.
It is a method which uses automation tools to run tests that repeat predefined actions, matches
the developed program’s probable and real results. If the project prospects and results align,
your project is behaving as it should, and you are likely bug free. If the two don’t align, still,
there is a problem that requires to be addressed. You’ll have to take a look at your code, alter
it, and continue to run tests until the actual and expected outcomes align.

Manual Testing:
Manual testing is a method used by software developers to run tests manually.

There are many manual testing types which are carried out manually as well as automatically.
These are,

Black Box Testing – It is a testing method to test functionalities and requirements of the system.
It does not test the internal part of the system.

White Box Testing – It is a testing method based on information of the internal logic of an
application’s code and also known as Glass box Testing. It works on Internal working code of
the system. Tests are based on coverage of code statements, branches, paths, conditions.

Integration Testing – Integrated modules testing method to verify joint functionality after
integration. Modules are typically code modules, individual applications, client and server
applications on a network, etc. This type of testing is especially applicable to client/server and
distributed systems.

System Testing – It is a technique to test whole system.

Comparison between Automation Testing and Manual testing

Automation Testing Manual Testing

Automation testing perform the same operation Manual testing is not reliable. Using this
each time method test execution is not accurate all the
time.
Automation testing is very much helpful To execute the test cases first time using manual
regressions in testing where code changes testing will be very much useful. But it is not
frequently. sure that it will catch the regression defects
under frequently changing requirements.
Automation testing will be useful to execute Manual testing will be useful when the test case
the set of test cases frequently. only needs to run once or twice.

After making Automation test suites, fewer To execute the test cases every time tester
testers required to execute the test cases. requires the same amount of time.
Automation testing can also be done on Using manual testing,testing on different
different machine with different OS platform machine with different OS platform
combination, concurrently. combination is not possible, concurrently. To
execute such task different testers are required.
Using Automation testing, testers can test It does not involve in programming task to fetch
complicated application too. hidden information.
Automation runs test cases significantly faster Manual testing is slower than automation.
than human resources. Running tests manually can be very time
consuming.
Some time it is not helpful in UI testing It is very much helpful in UI testing

Automation testing is very useful for To execute the Build Verification Testing
automating the Build Verification Testing (BVT) is very mundane and tiresome in manual
(BVT) & it is not mundane and tiresome. testing.
Initial cost of automation testing is more than Manual testing requires less cost than
manual testing but useful always. automation.
 Experiment 2
Design, develop, code and run the program in any suitable language to solve the
commission problem. Analyze it from the perspective of data flow testing, derive
at least 10 different test cases, execute these test cases and discuss the test results.

1. //Program (Dataflow testing for commission calculation)

2. # include<stdio.h>
3. int
main() 4.
{
5. int locks, stocks, barrels, tlocks, tstocks, tbarrels;
6. float lprice, sprice, bprice, ssales, lsales, bsales, sales, comm;
7. lprice=45.0;
8. sprice=30.0;
9. bprice=25.0;
10. tlocks=0;
11. tstocks=0;
12. tbarrels=0;
13. printf("\n Enter the number of locks and to exit the loop enter -1 for locks\n");
scanf("%d",&locks);
14. while(locks!=-1) {
15. printf("Enter the number of stocks and
barrels\n"); scanf("%d%d", &stocks, &barrels);
16. tlocks=tlocks+locks;
17. tstocks=tstocks+stocks;
18. tbarrels=tbarrels+barrels;
19. printf("\nEnter the number of locks and to exit the loop enter -1 for locks\n");
scanf("%d",&locks);
20. }
21. printf("\n total locks=%d\n",tlocks);
22. printf("\n total stocks=%d\n",tstocks);
23. printf("\n total barrels=%d\n",tbarrels);
24. lsales=lprice*tlocks;
25. ssales=sprice*tstocks;
26. bsales=bprice*tbarrels;
27. sales=lsales+ssales+bsales;
28.printf("\nThe total sales =
%f\n",sales); 29. if(sales>1800.0)
30. {
31. comm=0.10*1000.0;
32. comm=comm+0.15*800;
33. comm=comm+0.20*(sales-1800.0);
}
34. else if(sales>1000)
35. {
36. comm=0.10*1000.0;
37. comm=comm+0.15*(sales-1000);
}
38. else
39. comm=0.10*sales;
40. printf("The commission is = %f\n ",comm);
41. return 0;
42. }
 Test Case Name : Data Flow Testing for Commission Program
Experiment No : 2
Precondition : Enter -1 for locks to exit from input loop
Brief Description : Enter the locks, stocks and barrels > 0

Define /Use nodes for variables in the commission

problem
Variable Defined at node Used at node
Names
Lprice 7 24
Sprice 8 25
Bprice 9 26
Tlocks 10, 16 16,21,24
Tstocks 11, 17 17,22,25
Tbarrels 12, 18 18,23,26
Locks 13, 19 14,16
Stocks 15 17
Barrels 15 18
Lsales 24 27
Ssales 25 27
Bsales 26 27
Sales 27 28,29,33,34,37,39
31,32,33,
comm 32,33,37,40
36,37,39

Selected Define/Use Paths for Commission problem

Test Variable path Definition

Description (Begin and End Du paths clear?
case nodes)
ID
Check for lock <7-8-9-10-11-12-
1. price (7,24) YES
13-14-15-16-
DEF(lprice,7) 17-18-19-20-21-22-
and 23-24>
USE(lprice,24)
Check for <8-9-10-11-12-13-
2. (8,25) YES
Stock price 14-15-16-
DEF(sprice,8) 17-18-19-20-21-22-
and 23-24-25>
USE(sprice,25)
Check for <9-10-11-12-13-14-
3. (9,26) YES
barrel price 15-16-17-
DEF(bprice,9) 18-19-20-21-22-23-
and 24-25-26>
USE(bprice,26)
4 Check for total (10,16) <10-11-12-13-14- YES
. locks variable 15-16>
DEF((tlocks,10 <10-11-12-13-14-
) and (10,21) 15-16-17— NO
DEF(tlocks,16) 18-19-20-14-21>
) and 3 usage <10-11-12-13-14-
node(USE(tloc (10,24) 15-16-17— NO
ks,16),USE(tlo 18-19-20-14-21-
cks,21),USE(tl 22-23-24>
ocks,24) YES
(16,16) <16-16>

(16,21) <16-17-18-19-14- NO
21>
<16-17-18-19-20-
(16,24) 14-21-22-23-24> NO

Check for the total stocks (11,17) <11-12-13-14-15- YES

variable DEF((tstocks,11) 16-17>
5 and DEF(tstocks,17)) and 3 <11-12-13-14-15- NO
. usage (11,22) 16-17-18-19-
node(USE(tstocks,17,USE(t 20-14-21-22>
stocks,22),use(tstocks,25) <11-12-13-14-15-
(11,25) 16-17-18-19- NO
20-14-21-22-23-24-
25>
<17-17>
(17,17) YES

(17,22) <17-18-19-20-14- NO
21-22>
<17-18-19-20-14-
(17,25) 21-22-23-24- NO
25>

6 Check for the locks (13,14) <13-14> YES

. variable( DEF((locks,13)
DEF((locks,19) and
USE(locks,14),
USE(locks,16)
(13,16) <13-14-15-16> YES

(19,14) <19-20-14> YES

(19,16) <19-20-14-15-16> YES

Chec
7 k for (15,17) <15-16-17> YES
. Stock
variable
DEF(stoc
k,15) and
USE(stoc
k,17)
8 Check for <27-28>
Sales variable (27,28) YES
.
DEF(Sales,27) <27-28-29>
and (27,29) YES
USE(Sales,28)
USE(Sales,29) (27,33) <27-28-29-30-31- YES
USE(Sales,33), 32-33>
 USE(Sales,34),
USE(Sales,37), (27,34) <27-28-29-34> YES
USE(Sales,39)
(27,37) <27-28-29-34-35- YES
36-37>

(27,39) <27-28-29-34-38- YES

39>
9 Check for
. commission ((31,32,33),40) <31-32-33-40> YES
variable
DEF(comm,31,32,3 ((36,37),40) <34-35-40> YES
3) ,
EF(comm,36,37) (39,40) <39-40> YES
,DEF(comm,39)
USE(comm,40)
Experiment 3
Design, develop, code and run the program in any suitable language to solve the
NextDate problem. Analyze it from the perspective of decision table-based
testing, derive at least 10 different test cases, execute these test cases and discuss
the test results.
#include<stdio.h>
int check(int day,int month)
{
if((month==4||month==6||month==9 ||month==11) && day==31) return 1;

else

}
return 0;
int isleap(int year)
{
if((year%4==0 && year%100!=0) || year%400==0) return 1;
else
}
return 0;
int main()
{
int day,month,year,tomm_day,tomm_month,tomm_year; char flag;
do
{
flag='y';
printf("\nEnter the today's date in the form of dd mm yyyy\n");
scanf("%d%d%d",&day,&month,&year); tomm_month=month;
tomm_year= year; if(day<1 || day>31)
{
printf("value of day, not in the range 1...31\n");
flag='n';
}
if(month<1 || month>12)
{
printf("value of month, not in the range 1. .. 12\n"); flag='n';
}
else if(check(day,month))
{
printf("value of day, not in the range day<=30"); flag='n';
}
if(year<1812 || year>=2013)
{

printf("value of year, not in the range 1812. 2013\n");

flag='n';
}
if(month==2)
{
if(isleap(year) && day>29)
{
printf("Invalid date input for leap year\n"); flag='n';
}
else if(!(isleap(year))&& day>28)
{
printf("Invalid date input for not a leap year\n"); flag='n';
}
}
}while(flag=='n'); switch (month)
{
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:if(day<31)
tomm_day=day+1;

else
{
}
tomm_day=1; tomm_month=month+1;
break; case 4:
case 6:
case 9:
case 11: if(day<30)
tomm_day=day+1;
else
{
}
tomm_day=1; tomm_month=month+1;
break;
case 12: if(day<31)
tomm_day=day+1;
else
{
tomm_day=1; tomm_month=1; if(year==2013)
{
printf("\nThe next day is out of boundary value of year\n"); tomm_year=year+1;

}
else
tomm_year=year+1;
}
break; case 2:
if(day<28)
tomm_day=day+1;
else if(isleap(year)&& day==28)
tomm_day=day+1; else if(day==28 || day==29)
{
tomm_day=1; tomm_month=3;
}
break;
}
printf("\nNext day is : %d %d %d\n",tomm_day,tomm_month,tomm_year); return 0;
}
 NextDate problem Input Data Decision Table
RULES R1 R2 R3 R4 R5
F T T T T

Conditions

Actions

NextDate problem Decision Table Test cases for input data

Input Data
Case Id Description a b c Expected Actual Status
Output Output

4
 Experiment 4
Design, develop, code and run the program in any suitable object-oriented language
to solve the calendar problem. Analyze it from the perspective of OO testing, derive
test cases to test the method that increment the date and the method that
increments the month., execute these test cases and discuss the test results.

Levels of Object-Oriented Testing

Three or four levels of object-oriented testing are used, depending on the choice of what
constitutes a unit. If individual operations or methods are considered to be units, we have four
levels: operation/method, class, integration, and system testing. With this choice,
operation/method testing is identical to unit testing of procedural software. Class and
integration testing can be well renamed as intraclass and interclass testing. The second level,
then, consists of testing interactions among previously tested operations/methods. Integration
testing, which we will see is the major issue of object-oriented testing, must be concerned with
testing interactions among previously tested classes. Finally, system testing is conducted at the
port event level, and is (or should be) identical to system testing of traditional software. The
only difference is where system-level test cases originate.

Data Flow Testing for Object-Oriented Software

When we considered data flow testing it was restricted to a single unit. The issues of inheritance
and composition require a deeper view. The emerging consensus in the object-oriented testing
community is that some extension of data flow “should” address these special needs. , we saw
that data flow testing is based on identifying define and use nodes in the program graph of a
unit and then considering various define/use paths. Procedure calls in traditional software
complicate this formulation; one common work-around is to embed called procedures into the
unit tested (very much like fully flattened classes). we develop a revision of Event-Driven Petri
Nets (EDPNs) that exactly describes data flow among object-oriented operations. Within this
formulation, we can express the object-oriented extension of data flow testing

Example: ooNextDate
Very little documentation is required by UML at the unit/class level. Here, we add the class
responsibility collaboration (CRC) cards for each class, followed by the class pseudocode,
and then the program graphs for the class operations (see Figures ). CRC cards are not
formally part of UML.
program graphs for testIt and Date classes.

program graphs for Day class

program graphs for Month class.

program graphs for Year class.

Object-Oriented Unit testing
In this section, we revisit the question of whether a class or a method is a unit. Most of the
objectoriented literature leans toward the class-as-unit side, but this definition has problems.
The guidelines mentioned in Section also make sense for object-oriented software, but they do
not resolve whether classes or methods should be considered as units. A method implements a
single function, and it would not be assigned to more than one person, so methods might
legitimately be considered as units. The smallest compilation requirement is problematic.
Technically, we could compile a single-method class by ignoring the other methods in the class
(probably by commenting them out), but this creates an organizational mess. We will present
both views of objectoriented unit testing; you can let particular circumstances decide which is
more appropriate

Methods as Units
Superficially, this choice reduces object-oriented unit testing to traditional (procedural) unit
testing. A method is nearly equivalent to a procedure, so all the traditional specification-based
and code-based testing techniques apply. Unit testing of procedural code requires stubs and a
driver test program to supply test cases and record results. Mock objects are the object-oriented
analogue of this practice. Since instances of the nUnit framework are available for most object-
oriented languages, the assert mechanism in those frameworks is the most convenient choice.
When we look more closely at individual methods, we see the happy consequence of
encapsulation: they are generally simple. The pseudocode and corresponding program graphs
for the classes that make up the ooCalendar application are in Section Notice that the
cyclomatic complexities of the various operations are uniformly low. Date.increment has the
highest cyclomatic complexity, and it is only V(G) = 3. To be fair, this implementation is
intentionally simple—no checking is necessary for valid inputs. With validity checking, the
cyclomatic complexities would increase. As we saw in Chapter 6, equivalence class testing is
a good choice for logic-intensive units. The Date.increment operation treats the three
equivalence classes of days:
D1 = {day: 1 < = day < last day of the month}
D2 = {day: day is the last day of a non-December month}
D3 = {day: day is December 31}
At first, these equivalence classes appear to be loosely defined, especially D1, with its reference
to the unspecified last day of the month and no reference to which month. Thanks to
encapsulation, we can ignore these questions. (Actually, the questions are transferred to the
testing of the Month.increment operation.) Even though the cyclomatic complexity is low, the
interface complexity is quite high. Looking at Date.increment again, notice the intense
messaging: messages are sent to two operations in the Day class, to one operation in the Year
class, and to two operations in the Month class. This means that nearly as much effort will be
made to create the proper stubs as in identifying test cases. Another more important
consequence is that much of the burden is shifted to integration testing. In fact, we can identify
two levels of integration testing: intraclass and interclass integration.
Classes as Units
Treating a class as a unit solves the intraclass integration problem, but it creates other problems.
One has to do with various views of a class. In the static view, a class exists as source code.
This is fine if all we do is code reading. The problem with the static view is that inheritance is
ignored, but we can fix this by using fully flattened classes. We might call the second view the
compile-time view because this is when the inheritance actually “occurs.” The third view is the
execution-time view, when objects of classes are instantiated. Testing really occurs with the
third view, but we still have some problems. For example, we cannot test abstract classes
because they cannot be instantiated. Also, if we are using fully flattened classes, we will need
to “unflatten” them to their original form when our unit testing is complete. If we do not use
fully flattened classes, in order to compile a class, we will need all the other classes above it in
the inheritance tree. One can imagine the software configuration management implications of
this requirement. The class-as-unit choice makes the most sense when little inheritance occurs,
and classes have what we might call internal control complexity. The class itself should have
an “interesting” (mildly complex, nontrivial) StateChart, and there should be a fair amount of
internal messaging. To explore class-as-unit testing, we will revisit the windshield wiper
example with a more complex version
 Experiment 5
Design, develop, code and run the program in any suitable object-oriented
language to solve the currency converter problem. Analyze it from the
perspective of use case-based system testing, derive appropriate system test
cases, execute these test cases and discuss the test results.

The currency converter application converts U.S. dollars to any of four currencies: Brazilian
reals, Canadian dollars, European Community euros, and Japanese yen. The user can revise
inputs and perform repeated currency conversion

In the first step, sometimes called project inception, the customer/user describes the application
in very general terms. This might take the form of “user stories,” which are precursors to use
cases. From these, three types of system functions are identified: evident, hidden, and frill.
Evident functions are the obvious ones. Hidden functions might not be discovered immediately,
and frills are the “bells and whistles” that so often occur. Table lists the system functions for
the currency converter application
System Functions for Currency Converter application
Reference No Function Category
R1 Start application Evident
R2 End application Evident
R3 Input US dollar amount Evident
R4 R4 Select country Evident
R5 Perform conversion calculation Evident
R6 Clear user inputs and program outputs Evident Evident
R7 Maintain exclusive–or relationship among Hidden
countries
. R8 Display country flag images . Frill

The use case development begins with a very high-level view. Notice, as the succeeding levels
of use cases are elaborated, much of the early information is retained. It is convenient to have
a short, structured naming convention for the various levels of use cases. Here, for example,
HLUC refers to high-level use case (where would we be without acronyms?). Very few details
are provided in a high-level use case; they are insufficient for test case identification. The main
point of high-level use cases is that they capture a narrative description of something that
happens in the system to be built
 HLUC 1 Start application.
Description The user starts the currency conversion application in
Windows®.

HLUC 2 End application.

Description The user ends the currency conversion application in Windows.

HLUC 3 Convert dollars.

Description The user inputs a US dollar amount and selects a country; the
application computes and displays the equivalent in the currency
of the selected country.

HLUC 4 Revise inputs.

Description The user resets inputs to begin a new transaction.

HLUC 5 Repeated conversions, same dollar amount

Description The user inputs a US dollar amount and selects a country; the
application computes and displays the equivalent in the currency
of the selected country

Essential Use Cases

Essential use cases add “actor” and “system” events to a high-level use case. Actors in UML
are sources of system-level inputs (i.e., port input events). Actors can be people, devices,
adjacent systems, or abstractions such as time. Since the only actor is the User, that part of an
essential use case is omitted. The numbering of actor actions (port input events) and system
responses (port output events) shows their approximate sequences in time. In EUC3, for
example, human observers cannot detect the sequence of system responses 4 and 5; they would
appear to be simultaneous. Also, because some of the essential use cases are obvious, they are
deleted; however, the numbering still refers to the high-level use cases.
 Experiment 6
Design, develop, code and run the program in any suitable language to implement an
absolute letter grading procedure, making suitable assumptions. Determine the basis
paths and using them derive different test cases, execute these test cases and discuss the
test results.

#include<stdio.h> int main()

{
float per; char grade;
scanf("%f",&per); if(per>=90)
grade= 'A';
else if(per>=80 && per<90) grade ='B';
else if(per>=70 && per<80) grade ='C';
else if(per>=60 && per<70) grade='D';
else grade='E'; switch(grade)
{
case 'A': printf("\nExcellent"); break;
case 'B':printf("\nVery Good"); break;
case 'C' : printf("\nGood"); break;
case 'D': printf("\nAbove Average"); break;
case 'E': printf("\n Satisfactory"); break;
}
printf("\t The percentage = %f and grade is %c ",per,grade); return 0;
}
Absolute Grading Program With Line Numbers and Program Graph

int main()
{
float per; char grade;
1. scanf("%f",&per); 2. if(per>=90)
3. grade= 'A';
4. else if(per>=80 && per<90)
5. grade ='B';
6. else if(per>=70 && per<80)
7. grade ='C';
8. else if(per>=60 && per<70)
9. grade='D';
10. else grade='E';
11. switch(grade)
12. {
13. case 'A': printf("\nEXCELLENT"); break;
14. case 'B':printf("\nVery Good"); break;
15. case 'C' : printf("\nGood"); break;
16. case 'D': printf("\nAbove Average"); break;
17. case 'E': printf("\n Satisfactory"); break;
18. }
19. printf("\t The percentage = %f and grade is %c ",per,grade);
20. return 0;
}

Independent Paths
#Edges=25, #Nodes=18, #P=1
V(G)= E-N+2P = 25-18+2 = 09
P1: 1-2-4-6-8-10-11-17-19-20 E Grade
P2: 1-2-4-6-8-9-11-16-19-20 D Grade
P3: 1-2-4-6-7-11-15-19-20 C Grade
P4: 1-2-4-5-11-14-19-20 B Grade
P5: 1-2-3-11-13-19-20 A Grade
P6: 1-2-4-6-8-10-11-13-19-20
P7: 1-2-4-6-8-10-11-14-19-20
P8: 1-2-4-6-8-10-11-15-19-20
P9: 1-2-4-6-8-10-11-16-19-20

Program Graph

Pre-Conditions/Issues:
Percentage Per is a positive Float Number

Test Cases – Absolute Grading

 Experiment 7
Design, develop, code and run the program in any suitable language to implement the
binary search algorithm. Determine the basis paths and using them derive different test
cases, execute these test cases and discuss the test results.

#include<stdio.h>
int binary(int x[],int low,int high,int key)
{
int mid; while(low<=high)
{
mid=(low+high)/2; if(x[mid]==key) return mid; if(x[mid]<key) low=mid+1;
else high=mid-1;
}
return -1;
}
int main()
{
int a[20], key,i,n,succ; printf("Enter the n value"); scanf("%d",&n);
if(n>0)
{
printf("enter the elements in ascending order"); for(i=0;i<n;i++)
scanf("%d",&a[i]);
printf("enter the element to be searched"); scanf("%d",&key);
succ=binary(a,0,n-1,key); if(succ>=0)
printf("element found at %d location",succ+1); else
printf("element not found");
}
else
printf("number of elements should be greater than 0"); return 0;
}

Binary Search Function with line number

int binary(int x[],int low,int high,int key)
{
1. int mid;
2. while(low<=high)
{
mid=(low+high)/2;
3. if(x[mid]==key)
8. return mid;
4. if(x[mid]<key)
5. low=mid+1;
else
6. high=mid-1;
7. }
8. return -1;
9. }
Program Graph – for Binary Search
Independent Paths:
#Edges=11, #Nodes=9, #P=1 V(G)=E-N+2(P) = 11-9+2(1)=4
P1: 1-2-3-8-9
P2: 1-2-3-4-5-7-2
P3: 1-2-3-4-6-7-2
P4: 1-2-8-9

Preconditions/ Issues:
Array has elements in Ascending order T/F
Key element is in the array T/F
Array has ODD number of elements T/F
Test Cases – Binary Search
Paths Inputs Expected Remarks
X[] Key Output
P1: 1-2-3-8-9 {10,20,30,40,5 30 Success Key є X[] and
0} Key==X[mid]

P2: 1-2-3-4-5-7- {10,20,30,40,5 20 Repeat and Key < X[mid]

2 0} Success and Search 1st
Half
P3: 1-2-3-4-6-7- {10,20,30,40,5 40 Repeat and Key > X[] and
2 0} Success Search 2nd Half
P4: 1-2-8-9 {10,20,30,40,5 60 OR Repeat and Key є X[]
0} 05 Failure

P5: 1-2-8-9 Empty Any Key Failure Empty List