Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Experiment 1:
Write programs in ‘C’ Language to demonstrate the working of the following constructs:
1,1 do..while
a) Write a program to print the entered number in reverse order .Use do-while loop.Also Perform Sum and Multiplication with their digits.
#include <stdio.h>main(){Int n,d,x=1,mul=1,sum=0;Clrscr();Printf(“Enter the number of digits”);Scanf (“%d”,&d);Printf(“\n Enter the number which to be reversed”) ;Scanf(“%d”,&n);Printf(“\n Reversed Number”); do { i=n%10; Printf(“%d”,i); Sum=sum+i; mul=mul*i; n=n/10; x++; }while(x<=d);Printf(“\n Addition of digits %d”,sum);Printf(“\n multiplication of digits %d,mul);getch();}
OUTPUT:
Enter the number of digits:4
Enter the number which to be reversed:4321
Reversed number :1234
Addition of digits:10
Multiplication of digits:24
SRTIST,NALGONDA Page 1
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
b) Write a program to find the cubes of 1 to 10 numbers using do while loop
#include<stdio.h>#include<math.h>main(){ Int y,x=1;Printf(“\n Print the numbers and there cubes”);Printf(“\n”);do{y=pow(x,3);printf(“%4d%20d\n”,x,y);x++;}While(x<=5);}
OUTPUT:
Print the numbers and their cubes
1 12 83 274 645 125
SRTIST,NALGONDA Page 2
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
1.2 while:
a) Write a program to convert binary number to equivalent decimal number.
#include <conio.h> #include <stdio.h> #include<math.h> #include<process.h> main() { Long n; Int x,y=0,p=0; clrscr(); printf(“\n Enter binary number”); scanf(“%ld”,&n); while(n!=0) { x=n%10; if(x>1||x<0) { Printf(“\n Invalid Digit”); Exit(1); } y=y+x*pow(2,p); n=n/10; p++; } Printf(“\n Equivalent Decimal Number is%d.”y); getch(); }
OUTPUT:
Enter binary number:1111 Equivalent Decimal Number is 15 Enter a binary number:120 Invalid Digit.
SRTIST,NALGONDA Page 3
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
b) Write a program to enter few numbers and count the positive and negetive numbers Together with their sums,When 0 is entered program should be terminated.
#include<stdio.h>#include<conio.h>main(){int j=1,p=0,n=0,s=0,ns=0;clrscr();printf(“\n Enter Numbers(0)Exit:”); while(j!=0){ scanf(“%d”,&j); if(j>0){p++;s=s+j;}Else if(j<0){n++;ns=ns+j;}}printf(“\n Total Positive Numbers:%d”,p);printf(“\n Total Negative Numbers:%d”,n);printf(“\n Sum of Positive Numbers:%d”,s);printf(“\n Sum of Negative Numbers:%d”,ns);}
OUTPUT:
Enter Numbers(0) Exit: 1 2 3 4 5 -5 -4 -8
Total Positive Numbers :5
Total Negative Numbers:3
Sum of Positive Numbers:15
Sum of Negative Numbers:-17
SRTIST,NALGONDA Page 4
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
1.3 if…else
a) Read the values of a, b, c through the keyboard. Add them and after addition check if it is in the range of 100&200 or not. Print separate message for each.
#include<stdio.h>]main(){int a,b,c,d;clrscr();printf(“Enter Three Numbers a b c”);scanf(“%d%d%d”,&a,&b,&c);printf(“a=%d b=%d c=%d”,a,b,c);d=a+b+c;if(d<=200 & d>=100)printf(“\nsum is %d which is in between 100&200”,d);elseprintf(“\n sum is %d which is out of range “,d);}
OUTPUT:
Enter Three numbers a b c:50 52 54A=50 b=52 c=54 Sum is 156 which is in between 100 & 200
SRTIST,NALGONDA Page 5
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
b) Write a program to calculate the square of those numbers only whose least significant digit is 5.
#include<stdio.h>#include<conio.h>main(){int s,d;clrscr();printf(“\n Enter a Number”);scanf(“%d”,&s);d=s%10;if(d==5){s=s/10;printf(“\n squere =%d%d”,s*s++,d*d);}elsePrintf(“\n Invalid Number”);}
OUTPUT:
Enter a Number:25
Squere=625
SRTIST,NALGONDA Page 6
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
1.4 switch
a) Write a program to convert years into 1.Minuts 2.Hours 3.Days.4. Months 5. Seconds Using switch () statements.
#include<stdio.h>#include<conio.h>main (){long ch, min, hrs, ds, mon, yrs, se;clrrscr();printf(“\n[1]MINUTES”);printf(“\n [2] HOURS”);printf(“\n[3] DAYS”);printf(“\n[4] MONTHS”);printf(“\n[5] SECONDS”);printf(“\n[0] EXIT”);printf(“\n Enter your choice”);scanf(“%ld”,&ch);if(ch>0&&ch<6){Printf(“Enter years”);Scanf(“%ld”,&yrs);}mon=yrs*12;ds=mon*30;hrs=ds*24;min=hrs*60;se=min*60; switch(ch){case 1:printf(“\n minutes:%ld”,min);break;
case 2:printf(“\n hours:%ld”,hrs);break;
SRTIST,NALGONDA Page 7
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
case 3:printf(“\n days:%ld”,ds);break;case 4:printf(“\n months:%ld”,mon);break;
case 5:printf(“\nseconds:%ld”,se);break;
case 0:printf(“\n terminated”);break;
default:printf(\n invalid choice”);}getch();}
OUTPUT:
[1]MINUTES
[2]HOURS
[3]DAYS
[4]MONTHS
[5]SECONDS
[0]EXIT
Enter your choice:4
Enter years:2
Months:24
SRTIST,NALGONDA Page 8
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
1.5 for
a) Write a program to display numbers from 1 to 16.Use Incrementation operation in the body of the loop for more than once.
#include<stdio.h>#include<conio.h>main(){int i, c=0;clrscr();for(i=0;i<=15;){i++;printf(“%5d”,i);i=i+1;printf(“%5d”,i);c++;}Printf(“\n\n The body of the loop is executed for %d times.”c);}
OUTPUT:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
The body of the loop is executed for 8 times.
SRTIST,NALGONDA Page 9
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
b) Write a program to evaluate the series given in comments./*x=1/1+1/4+1/9…1/n2*//*y=1/1+1/8+1/27…1/n3*/
#include<stdio.h>#include<conio.h>main(){int i,n;float x=0,y=0;clrscr();printf(“Enter value of n”);scanf(“%d”,&n);for(i=1;i<=n;i++){x=x+(1/pow(I,2));y=y+(1/pow(I,3));}Printf(“value of x=%f”,x);Printf(“\n value of y=%f”,y);getch();}
OUTPUT:
Enter value of n: 2
Value of x=1.2500
Value of y=1.12500
SRTIST,NALGONDA Page 10
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Experiment 2:
2.a. program written in c language for Matrix multiplication.
#include<stdio.h>
int main()
{
int a[5][5],b[5][5],c[5][5],
i,j,k,sum=0,m,n,o,p;
printf("\nEnter the row and column of first matrix");
scanf("%d %d",&m,&n);
printf("\nEnter the row and column of second
matrix”);
scanf("%d %d",&o,&p);
if(n!=o)
{
printf("Matrix mutiplication is not possible”);
printf("\n Column of first matrix must be same
as row of second matrix");
}
Else
{
printf("\nEnter the First matrix->");
for(i=0;i<m;i++)
for(j=0;j<n;j++)
scanf("%d",&a[i][j]);
SRTIST,NALGONDA Page 11
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
printf("\nEnter the Second matrix->");
for(i=0;i<o;i++)
for(j=0;j<p;j++)
scanf("%d",&b[i][j]);
printf("\nThe First matrix is\n");
for(i=0;i<m;i++){
printf("\n");
for(j=0;j<n;j++){
printf("%d\t",a[i][j]);
}
}
printf("\nThe Second matrix is\n");
for(i=0;i<o;i++)
{
printf("\n");
for(j=0;j<p;j++)
{
printf("%d\t",b[i][j]);
}
}
for(i=0;i<m;i++)
for(j=0;j<p;j++)
c[i][j]=0;
for(i=0;i<m;i++)
{ //row of first matrix
SRTIST,NALGONDA Page 12
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
for(j=0;j<p;j++)
{ //column of second matrix
sum=0;
for(k=0;k<n;k++)
sum=sum+a[i][k]*b[k][j];
c[i][j]=sum;
}
}
}
printf("\nThe multiplication of two matrix is\n");
for(i=0;i<m;i++)
{
printf("\n");
for(j=0;j<p;j++)
{
printf("%d\t",c[i][j]);
}
}
return 0;
}
SRTIST,NALGONDA Page 13
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
2. b. A program written in c language for matrix multiplication fails “Introspect the causes for its failure and write down the possible reasons for its failure”.
Alogrithm:
Multiplication of two matrixes:
Rule: Multiplication of two matrixes is only possible if first matrix has size m X n and other matrix
has size n x r. Where m, n and r are any positive integer.
Multiplication of two matrixes is defined as
Where 1 ≤ i ≤ m and 1 ≤ j ≤ n
For example:
Suppose two matrixes A and B of size of 2 x 2 and 2 x 3 respectively:
SRTIST,NALGONDA Page 14
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
SRTIST,NALGONDA Page 15
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Experiment 3:
Take ATM system and study its system specifications and report the various bugs.
Software Requirement Specification Report
Purpose of Project
This project is part of the requirement in completing the Software Engineering course, which
is a module in the Bachelor of Science degree program done at ASeT / EXED in Kingston, Jamaica,
for the period 2002-2004.
The purpose of the project is to demonstrate the application of software engineering in a
practical scenario and to prove full understanding of the subject and its function and relevance.
Project Definition
This project is aimed at creating an island wide computerized telephone call-time purchasing
system in Jamaica for pre-paid cellular service. The system is aimed at making it possible to use any
credit or debit card for the purchase of cellular telephone call-time. There are many Automated
Teller Machines (ATM’s) all over Jamaica. They all accept credit and debit cards. They are open
and accessible 24 hours a day. As a result, this technology can be utilized to make it easier to access
credit for pre-paid cellular telephone calls. This project aims to achieve that goal.
Description of Existing System & Problems
There are three major cellular telephone companies in Jamaica one of which offers land line
service. However, the problem is with the cellular service for pre-paid customers. There are several
packages for service and payment. The most common of which is the pre-paid service.
The pre-paid service is the most economical to consumers. It allows a customer to own a
telephone and can always receive calls free of any charge. To make calls, the customer has to
purchase call-time in advance as opposed to making calls and paying a bill at the end of the month.
To obtain credit each company produces a separate card. Cards have different monetary values. Each
card has a unique id number. Each company installs an automated telephone service that, accepts a
call, validates the id given and applies the appropriate credit to the customers account. After this the
customer can make calls until the credit expires.
SRTIST,NALGONDA Page 16
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
The problem that arises is that places which sell phone cards are numerous but most are
closed late at nights and on public holidays to include Sundays. As a result people are forced to
ensure they have credit in advance for these occasions. Notwithstanding, credit often runs out, which
is a problem and inconvenience in emergencies. This project is based on utilizing present
technologies of available ATM’s and making it possible for customers to gain credit anytime and
anywhere there is an ATM by using a credit or debit card.
Scope of Project
The project will utilize available resources and will not require the purchase of additional
equipment. No additional personnel will be required by the telephone companies or banks. Only
available ATM’s will be used. The project is aimed at aiding cellular telephone owners, who have
pre-paid packages and are capable of using an ATM. They should not be visually impaired and they
should be able to read.
The project is not for bill payment, only purchase of advance talk-time. Talk-time credit will
be subject to the same conditions as applicable to cards. This includes limited duration after purchase
to utilize the credit. The minimum credit will be the same as cards ($50) and have no maximum limit
as opposed to cards.
For persons with credit or debit cards where ATM’s are accessible, this system will eliminate the
need for phone cards. However, for customers who do not have credit or debit cards, they will have
to continue purchasing phone cards. Also, in areas where there is no ATM, phone cards will be
necessary. So, this project will not eliminate but minimize the need for phone cards which is costly
to produce. Telephone companies will benefit from the reduced costs. When a customer attends an
ATM for other transactions, time and money can be saved by performing telephone transactions at
the same time and place.
Customers will be required to be in good standing with their banks and have sufficient funds
to use the service successfully.
No new interface will be setup ATM’s, only an additional item on the menu to purchase call-
timer credit. One will only need to follow the instructions as with other transactions. No experience,
training or change in procedures will be required.
SRTIST,NALGONDA Page 17
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Functional Requirements
a) Pre-requisites
For use of ATM
Activated credit/debit card with PIN (Personal Identification Number)
A bank a/c with sufficient funds if using debit card ($100 or more)
A cellular telephone with pre-paid service from a local provider
b) Input Requirements
7 digit telephone #
Dollar quantity of credit required
Telephone company name/id
Telephone company a/c #
Telephone # to call respective phone company
c) Output Requirements
Transfer of correct sum from customers’ a/c to Telephone company’s a/c
Transaction receipt
Credit automatically added to customers’ phone a/c
d) Procedure (Operation of System)
Use appropriate card at ATM to access system
Select option of ‘Phone Credit’ from main menu
Select a/c to use depending on type of card
Select phone company from list
Enter customer telephone #. The system will call the phone company and check its db to
verify the validity of the given phone number and a/c type.
Enter credit amount required. The system will check balance of the customers’ a/c for
sufficient funds. The system will automate a transfer of funds from customers’ to phone
company’s a/c.
Production of receipt will signal end of transaction.
Appropriate error messages where applicable.
Non-Functional Requirements
a) Developmental Constraints
SRTIST,NALGONDA Page 18
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
The system will depend on the existing banking services provided at ATM’s. However,
minor additions will be made to accommodate the phone service. It involves being limited to the
interface of ATM’s in terms of screen size, option buttons, locations and working with the
systems of the bank and telephone companies. The user interface will have to be consistent with
that of the banks. Permission must also be granted by these entities.
The telephone companies must have accounts for transfers to be made. The system of the
phone companies must also be configured to accept the transactions by adding the time paid for
to respective telephone accounts.
The systems of the banks, telephone companies and call-time purchasing must be integrated
to work.
b) Constraint on Services
The only service the system will provide is that of call-time. It will be restricted to pre-paid
customers because that is where the problem is confined. It is not for bill payment for calls
already made. Customers must make a minimum purchase ($50), which for economy must
exceed tax and charges.
c) Data Constraint
Most data requirement will be built-in. Only telephone # and a dollar amount in figures will
be required as input by the customer, which will be subject to validation. A minimum sum is
required but no maximum or increments.
d) Time Constraint
The system is confined to be completed in less than 2 months. The team only had a part of
each weekend to develop the project. A schedule was worked out and described in the schedule
feasibility. Teams were also small, which made it even more challenging. This team only has to
persons.
System Design
SRTIST,NALGONDA Page 19
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Architecture of Application
Dataflow Diagram
SRTIST,NALGONDA Page 20
Customer
ATM Bank
Phone Co.
DB
DB
Input data, get receipt & credit Verify a/c, update a/c
Verify Ph. #, assign credit
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Tables
Customer
Phone Co. Developer
Card Phone
SRTIST,NALGONDA Page 21
Customer
Bank ATM Services
Select Ph. Co.
Enter Ph. #
Select a/c
Enter $ amt.
Check customer a/c bal.
Verify Ph. #
Update customer bank bal.
Update customer
Credit a/c
Transaction receipt
Visual display
confirm
Card# phone# phone id
Phone id name a/c # bank name
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Bank a/c
ERD
Data Dictionary
Entity Field Type Data Type Relationship Integrity Description
Customer
Name
Card#
a/c#
Primary
Foreign
Foreign
Integer
‘’
‘’
1:M
Not Null
NN
NNAssigned by
SRTIST,NALGONDA Page 22
Phone#
Phone Co
Customer Transaction
CardDeveloperUnique Ph. id
Bank a/c
has
has joins Belongs to
performs
hasBelongs to
Customer card#PIN bank id Phone # owner name time bal.
Name card id Name a/c #
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
phone#
PIN
Foreign
foreign
‘’
‘’
NN
NN
bank
“ Ph Co
‘’ bank
chosen by
custom
Ph. Co.
Ph id #
Name
primary Alphanum.
string
1:M
NN
NN
Chosen by ph.
Co
‘’
Developer
a/c#
bank
name
Foreign
Primary
integer
string
‘’
1:M
NN
‘’
‘’
Assigned by
bank
Chosen by
develop.
‘’
A/c
Owner name
a/c #
Foreign
Primary
String
integer
1:M
NN
NN
Ass. At creation
Generated by
SRTIST,NALGONDA Page 23
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
bank
Phone
Phone #
Owner name
Time bal.
Primary
foreign
Integer
String
time
1:M
NN
NN
Unlimited
Ass. By ph. Co.
Adopted from
owner
Gen. by ph. Co.
Card
Card#
a/c#
PIN
Primary
Foreign
primary
Integer
‘’
‘’
1:M
NN
‘’
‘’
Ass. By bank
Gen. by bank
Ass. By
customer
Bank
Name
Card id#
Primary
foreign
String
Integer
1:M
NN
NN
Chosen by bank
Gen. by bank
SRTIST,NALGONDA Page 24
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
SRTIST,NALGONDA Page 25
start
end
Input phone #
Input card & PIN at ATM
Select phone option
Select phone Co.
end
no yes
A
B
D
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
SRTIST,NALGONDA Page 26
A
Dial unique ph. id for company
Access ph. Sys. db
Is Ph. # valid
Is card a debit card
yes
Error message B
no
yes
no
Select a/c
Input $ amt.
Access customer a/c from bank’s db Is sufficient
funds in a/c
no
yes
C
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
SRTIST,NALGONDA Page 27
Dial ph. Co. unique #
Access ph. Sys. db
Update customer
call-credit
Access a/c of ph. Co. and update a/c
Access a/c of developer and update a/c
Print receipt D
C
Inform user of a/c phone call-time update
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Prototype
Testing
Black box Testing
The system will be tested independently of the developers using all possible data values
(valid and invalid) to ensure that the correct results are obtained at all times. The system can not be
allowed to do anything undesirable because a lot of money can be lost.
White box Testing
The logics of the system will be put to the full test. The software must integrate and interact
with the other systems as desired. The logics must be free of fault. There should be no way that the
system can be manipulated by anyone.
Integration Testing
How the system works with that of the banks and phone companies will be put to rigorous
testing. There should be no undue delay, crash or errors. The software must work as expected with
each of the other systems.
System Testing
The entire system when integrated must be harmonious and produce the desired results. It
must be fast and produce good error messages where applicable. Any logical or system error which
was undetected before must be ironed out at this last stage.
Feasibility Study Report
Technical Feasibility
The main technical issue is how the system will contact the telephone companies to access
their db. The rationale is that the ATM’s of different banks integrate by using the online concept.
Since the ATM’s are already networked via telephone lines then a simple phone call from the ATM
to a phone company can access their system and db.
SRTIST,NALGONDA Page 28
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Providing the banks and phone companies agree, then only minor modifications are required
to both systems. The phone company will be required to accept a call with special parameters, verify
given telephone number and update a customer call-time credit. The banks system must include an
option for phone transaction, and in addition to its present checks update bank and developer a/c.
The software will have to be implemented on the banks h/w and be an integral part of its
ATM software which is already in place. The phone companies already have the technical expertise
to upgrade their system and the development team is sufficiently skilled.
Operational Feasibility
Anything that will make life more comfortable is worth pursuing. The experience of this
development team is sufficient proof that customers are experiencing difficulties obtaining cards at
nights and public holidays to include Sundays.
This system stands to benefit the phone companies significantly. If they can make more sales
during slow periods, at practically no cost, there is no way they will refuse. The banks will receive
payment for the use of their machines and system, which is fair. The developers will also earn per
transaction. The system is not complex and is a minor addition to existing systems. It is a win
situation for all concerned and is not expected to be refused as the economic gains can be significant.
Implementation Plan
Arrange with bank to conduct system test to ensure that integration is smooth. First a
Sunday will be chosen to do acceptance testing. This is a day when the machines are
least used.
Prepare conversion plan: To stay on the side of caution the smallest bank will be
selected and the system implemented ‘cold turkey’ method because of its simplicity.
The system will be constantly monitored over its infancy. Training schedule will be
prepared for bank and telephone companies.
There is no db to implement. The db of the bank and phone company is all that is
needed.
Train internal users at bank and phone companies as to how the system works.
Actions in case of problems and complaints. The likely problems that may occur. The
SRTIST,NALGONDA Page 29
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
developers are the owners of the system and will be on call to rectify faults. Training
will be limited as there will be no significant change to the system in place, but to
explain how the various accounts will be updated automatically and how to interpret
these information for customers. All bank staff must be made acquainted so this will
take some time and based on the number of banks seminars over a 2 months period
will be implemented.
Execute implementation plan in the order of training, acceptance testing, ‘cold
turkey’ execution and maintenance.
Conclusion & Recommendation
From the feasibility studies carried out it is conclusive that the project is feasible and will be
economically viable. All parties involved including the customers stand to benefit. As a result it is
the recommendation of this development team that the system can be completed and implemented.
Experiment 4:
Write the test cases for any known application
Initial Functional Test Cases for ATM System
SRTIST,NALGONDA Page 30
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
The following initial test cases can be identified early in the design process as a vehicle for checking that the implementation is basically correct. No attempt has been made at this point to do thorough testing, including all possible errors and boundary cases. That needs to come later. These cases represent an initial check that the functionality specified by the use cases is present.
Some writers would argue for developing test cases like these in place of use cases. Here, they are presented as a vehicle for "fleshing out" the use cases, not as a substitute for them.
Use CaseFunction Being Tested
Initial System State
Input Expected Output
System Startup
System is started when the switch is turned "on"
System is offActivate the "on" switch
System requests initial cash amount
System Startup
System accepts initial cash amount
System is requesting cash amount
Enter a legitimate amount
System is on
System Startup
Connection to the bank is established
System has just been turned on
Perform a legitimate inquiry transaction
System output should demonstrate that a connection has been established to the Bank
System Shutdown
System is shut down when the switch is turned "off"
System is on and not servicing a customer
Activate the "off" switch
System is off
System Shutdown
Connection to the Bank is terminated when the system is shut down
System has just been shut down
Verify from the bank side that a connection to the ATM no longer exists
SessionSystem reads a customer's ATM card
System is on and not servicing a customer
Insert a readable card
Card is accepted;System asks for entry of PIN
SessionSystem rejects an unreadable card
System is on and not servicing a customer
Insert an unreadable card
Card is ejected;System displays an error screen;System is ready to start a new session
SessionSystem accepts customer's PIN
System is asking for entry of PIN
Enter a PINSystem displays a menu of transaction types
SessionSystem allows customer to perform a transaction
System is displaying menu of transaction types
Perform a transaction
System asks whether customer wants another transaction
Session System allows multiple transactions
System is asking whether customer
Answer yes System displays a menu of transaction
SRTIST,NALGONDA Page 31
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Use CaseFunction Being Tested
Initial System State
Input Expected Output
System Startup
System is started when the switch is turned "on"
System is offActivate the "on" switch
System requests initial cash amount
in one sessionwants another transaction
types
Session
Session ends when customer chooses not to do another transaction
System is asking whether customer wants another transaction
Answer noSystem ejects card and is ready to start a new session
TransactionIndividual types of transaction will be tested below
TransactionSystem handles an invalid PIN properly
A readable card has been entered
Enter an incorrect PIN and then attempt a transaction
The Invalid PIN Extension is performed
WithdrawalSystem asks customer to choose an account to withdraw from
Menu of transaction types is being displayed
Choose Withdrawal transaction
System displays a menu of account types
WithdrawalSystem asks customer to choose a dollar amount to withdraw
Menu of account types is being displayed
Choose checking account
System displays a menu of possible withdrawal amounts
WithdrawalSystem performs a legitimate withdrawal transaction properly
System is displaying the menu of withdrawal amounts
Choose an amount that the system currently has and which is not greater than the account balance
System dispenses this amount of cash;System prints a correct receipt showing amount and correct updated balance;System records transaction correctly in the log (showing both message to the bank and approval back)
Withdrawal
System verifies that it has sufficient cash on hand to fulfill the request
System has been started up with less than the maximum withdrawal amount in cash on hand;System is requesting a withdrawal amount
Choose an amount greater than what the system currently has
System displays an appropriate message and asks customer to choose a different amount
SRTIST,NALGONDA Page 32
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Use CaseFunction Being Tested
Initial System State
Input Expected Output
System Startup
System is started when the switch is turned "on"
System is offActivate the "on" switch
System requests initial cash amount
Withdrawal
System verifies that customer's balance is sufficient to fulfill the request
System is requesting a withdrawal ammount
Choose an amount that the system currently has but which is greater than the account balance
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Withdrawal
A withdrawal transaction can be cancelled by the customer any time prior to choosing the dollar amount
System is displaying menu of account types
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Withdrawal
A withdrawal transaction can be cancelled by the customer any time prior to choosing the dollar amount
System is displaying menu of dollar amounts
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
DepositSystem asks customer to choose an account to deposit to
Menu of transaction types is being displayed
Choose Deposit transaction
System displays a menu of account types
DepositSystem asks customer to enter a dollar amount to deposit
Menu of account types is being displayed
Choose checking account
System displays a request for the customer to type a dollar amount
DepositSystem asks customer to insert an envelope
System is displaying a request for the customer to type a dollar amount
Enter a legitimate dollar amount
System requests that customer insert an envelope
Deposit System performs a legitimate deposit transaction properly
System is requesting that customer insert an envelope
Insert an envelope System accepts envelope;System prints a correct receipt showing amount and correct updated balance;System records transaction correctly in
SRTIST,NALGONDA Page 33
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Use CaseFunction Being Tested
Initial System State
Input Expected Output
System Startup
System is started when the switch is turned "on"
System is offActivate the "on" switch
System requests initial cash amount
the log (showing message to the bank, approval back, and acceptance of the envelope)
Deposit
A deposit transaction can be cancelled by the customer any time prior to inserting an envelope
System is displaying menu of account types
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Deposit
A deposit transaction can be cancelled by the customer any time prior to inserting an envelope
System is requesting customer to enter a dollar amount
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Deposit
A deposit transaction can be cancelled by the customer any time prior to inserting an envelope
System is requesting customer to insert an envelope
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Deposit
A deposit transaction is cancelled automatically if an envelope is not inserted within a reasonable time
System is requesting customer to insert an envelope
Wait for the request to time out
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
TransferSystem asks customer to choose an account to transfer from
Menu of transaction types is being displayed
Choose Transfer transaction
System displays a menu of account types specifying transfer from
TransferSystem asks customer to choose an account to transfer to
Menu of account types to transfer from is being displayed
Choose checking account
System displays a menu of account types specifying transfer to
Transfer System asks customer Menu of account Choose savings System displays a
SRTIST,NALGONDA Page 34
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Use CaseFunction Being Tested
Initial System State
Input Expected Output
System Startup
System is started when the switch is turned "on"
System is offActivate the "on" switch
System requests initial cash amount
to enter a dollar amount to transfer
types to transfer to is being displayed
accountrequest for the customer to type a dollar amount
TransferSystem performs a legitimate transfer transaction properly
System is displaying a request for the customer to type a dollar amount
Enter a legitimate dollar amount
System prints a correct receipt showing amount and correct updated balance;System records transaction correctly in the log (showing both message to the bank and approval back)
Transfer
A transfer transaction can be cancelled by the customer any time prior to entering dollar amount
System is displaying menu of account types specifying transfer from
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Transfer
A transfer transaction can be cancelled by the customer any time prior to entering dollar amount
System is displaying menu of account types specifying transfer to
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Transfer
A transfer transaction can be cancelled by the customer any time prior to entering dollar amount
System is requesting customer to enter a dollar amount
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
InquirySystem asks customer to choose an account to inquire about
Menu of transaction types is being displayed
Choose Inquiry transaction
System displays a menu of account types
Inquiry System performs a legitimate inquiry transaction properly
System is displaying menu of account types
Choose checking account
System prints a correct receipt showing correct balance;System records transaction correctly in
SRTIST,NALGONDA Page 35
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Use CaseFunction Being Tested
Initial System State
Input Expected Output
System Startup
System is started when the switch is turned "on"
System is offActivate the "on" switch
System requests initial cash amount
the log (showing both message to the bank and approval back)
Inquiry
An inquiry transaction can be cancelled by the customer any time prior to choosing an account
System is displaying menu of account types
Press "Cancel" key
System displays an appropriate message and offers customer the option of choosing to do another transaction or not.
Invalid PIN Extension
Customer is asked to reenter PIN
Enter an incorrect PIN;Attempt an inquiry transaction on the customer's checking account
Customer is asked to re-enter PIN
Invalid PIN Extension
Correct re-entry of PIN is accepted
Request to re-enter PIN is being displayed
Enter correct PINOriginal transaction completes successfully
Invalid PIN Extension
A correctly re-entered PIN is used for subsequent transactions
An incorrect PIN has been re-entered and transaction completed normally
Perform another transaction
This transaction completes successfully as well
Invalid PIN Extension
Incorrect re-entry of PIN is not accepted
Request to re-enter PIN is being displayed
Enter incorrect PIN
An appropriate message is displayed and re-entry of the PIN is again requested
Invalid PIN Extension
Correct re-entry of PIN on the second try is accepted
Request to re-enter PIN is being displayed
Enter incorrect PIN the first time, then correct PIN the second time
Original transaction completes successfully
Invalid PIN Extension
Correct re-entry of PIN on the third try is accepted
Request to re-enter PIN is being displayed
Enter incorrect PIN the first time and second times, then correct PIN the third time
Original transaction completes successfully
Invalid PIN Extension
Three incorrect re-entries of PIN result
Request to re-enter PIN is being
Enter incorrect PIN three times
An appropriate message is displayed;
SRTIST,NALGONDA Page 36
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Use CaseFunction Being Tested
Initial System State
Input Expected Output
System Startup
System is started when the switch is turned "on"
System is offActivate the "on" switch
System requests initial cash amount
in retaining card and aborting transaction
displayedCard is retained by machine;Session is terminated
SRTIST,NALGONDA Page 37
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Experiment 5:
Create a test plan document for Library Management system
5.1. Background
The Library Management System is an online application for assisting a librarian in managing a book library in a University. The system would provide basic set of features to add/update clients, add/update books, search for books, and manage check-in / checkout processes. Our test group tested the system based on the requirement specification.
5.2. Introduction
This test report is the result for testing in the LMS. It mainly focuses on two problems: what we will test and how we will test.
5.3. Result
5.3.1 GUI test
Pass criteria: librarians could use this GUI to interface with the backend library database without any difficulties
Result: pass
5.3.2 Database test
Pass criteria: Results of all basic and advanced operations are normal (refer to section 4)
Result: pass
5.3.3 Basic function test
5.3.4 Add a student
Pass criteria:
Each customer/student should have following attributes: Student ID/SSN (unique), Name, Address and Phone number.
Result: pass
The retrieved customer information by viewing customer detail should contain the four attributes.
Result: pass
5.3.5 Update/delete student
Pass criteria:
The record would be selected using the student ID
Result: pass
SRTIST,NALGONDA Page 38
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Updates can be made on full. Items only: Name, Address, Phone number
Result: pass
The record can be deleted if there are no books issued by user.
Result: Partially pass. When no books issued by user, he can be deleted. But when there are books
Issued by this user, he was also deleted. It is wrong.
The updated values would be reflected if the same customer's ID/SSN is called for.
Result: pass
If customer were deleted, it would not appear in further search queries.
Result: pass
5.3.6 Add a book
Pass criteria:
Each book shall have following attributes: Call Number, ISBN, Title, Author name.
Result: pass
The retrieved book information should contain the four attributes.
Result: pass
5.3.7 Update/delete book
Pass criteria:
The book item can be retrieved using the call number
Result: did not pass. Can not retrive using the call number
The data items which can be updated are: ISBN, Title, Author name
Result: pass
The book can be deleted only if no user has issued it.
Result: partially pass. When no user has issued it, pass. When there are user having issued it,
did not pass
The updated values would be reflected if the same call number is called for
Result: pass
If book were deleted, it would not appear in further search queries.
Result: pass
SRTIST,NALGONDA Page 39
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
5.3.8 Search for book
Pass criteria:
The product shall let Librarian query books’ detail information by their ISBN number or Author or Title.
Result: pass
The search results would produce a list of books, which match the search parameters with following Details: Call number, ISBN number, Title, Author
Result: pass
The display would also provide the number of copies which is available for issue
Result: pass
The display shall provide a means to select one or more rows to a user-list
Result: pass
A detailed view of each book should provide information about check-in/check out status, with the borrower’s information.
Result: pass
The search display will be restricted to 20 results per page and there would be means to navigate from sets of search results.
Result: pass
The user can perform multiple searches before finally selecting a set of books for check in or checkout. These should be stored across searches.
Result: pass
A book may have more than one copy. But every copy with the same ISBN number should have same detail information.
Result: pass
The borrower’s list should agree with the data in students’ account
Result: pass
5.3.9 Check-in book
Pass criteria:
Librarians can check in a book using its call number
Result: pass
The check-in can be initiated from a previous search operation where user has selected a set of books.
Result: pass
The return date would automatically reflect the current system date.
Result: did not pass.
SRTIST,NALGONDA Page 40
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Any late fees would be computed as difference between due date and return date at rate of 10 cents a day.
Result: did not pass
A book, which has been checked in once, should not be checked in again
Result: pass
5.3.10 Check-out book
Pass criteria:
Librarians can check out a book using its call number
Result: pass
The checkout can be initiated from a previous search operation where user has selected a set of books.
Result: pass
The student ID who is issuing the book would be entered
Result: pass
The issue date would automatically reflect the current system date.
Result: did not pass
The due date would automatically be stamped as 5 days from current date.
Result: did not pass
A book, which has been checked out once, should not be checked out again
Result: pass
A student who has books due should not be allowed to check out any books
Result: did not pass
The max. No of books that can be issued to a customer would be 10. The system should not allow checkout of books beyond this limit.
Result: pass
5.3.11 View book detail
Pass criteria:
This view would display details about a selected book from search operation
Result: pass
The details to be displayed are: Call number, IBN, Title, Author, Issue status (In library or checked out), If book is checked out it would display, User ID & Name, Checkout date, Due date
Result: for checkout date and due date, did not pass
Books checked in should not display user summary
Result: pass
SRTIST,NALGONDA Page 41
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Books checked out should display correct user details.
Result: pass
5.3.12 View student detail
Pass criteria:
Librarians can select a user record for detailed view
Result: pass
The detail view should show:
a.User name, ID, Address & Phone number
Result: pass
b. The books issued by user with issue date, due date, call number, title
Result: did not pass
c. Late fees & Fines summary and total
Result: did not pass
The display should match existing user profile
Result: pass
The books checked out should have their statuses marked
Result: pass
The book search query should show the user id correctly.
Result: pass
5.3.13 Network test
Pass criteria: Results of operations (ping, ftp and ODBC connectivity check) are normal
Result: did not test this item, because no enough machines and no available envirenment.
5.4 ENVIRONMENTAL used
5.4.1 Hardware: Core2Duo
5.4.2 Software: Microsoft Windows XP
5.5 RESOURCES
5.5.1 Developers of the system are involved in testing process (debugging, unit testing, even integrity testing)
5.5.2 Users of the system are involved in testing process (integrity testing)
SRTIST,NALGONDA Page 42
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Experiment 6:
Study of Any Testing Tool (Win Runner)
Win Runner is a program that is responsible for the automated testing of software. Win Runner is a Mercury Interactive’s enterprise functional testing tool for Microsoft windows applications.
Importance of Automated Testing:
1. Reduced testing time 2. Consistent test procedures – ensure process repeatability and resource independence.
Eliminates errors of manual testing 3. Reduces QA cost – Upfront cost of automated testing is easily recovered over the lifetime of
the product
4. Improved testing productivity – test suites can be run earlier and more often
5. Proof of adequate testing
6. For doing tedious work – test team members can focus on quality areas.
Win Runner Uses:
1. With Win Runner sophisticated automated tests can be created and run on an application. 2. A series of wizards will be provided to the user, and these wizards can create tests in an
automated manner.
3. Another impressive aspect of Win Runner is the ability to record various interactions, and transform them into scripts. Win Runner is designed for testing graphical user interfaces.
4. When the user makes an interaction with the GUI, this interaction can be recorded. Recording the interactions allows to determining various bugs that need to be fixed.
5. When the test is completed, Win Runner will provide with detailed information regarding the results. It will show the errors that were found, and it will also give important information about them. The good news about these tests is that they can be reused many times.
6. Win Runner will test the computer program in a way that is very similar to normal user interactions. This is important, because it ensures a high level of accuracy and realism. Even if an engineer is not physically present, the Recover manager will troubleshoot any problems that may occur, and this will allow the tests to be completed without errors.
7. The Recover Manager is a powerful tool that can assist users with various scenarios. This is important, especially when important data needs to be recovered.
The goal of Win Runner is to make sure business processes are properly carried out. WinRunner uses TSL, or Test Script Language.
SRTIST,NALGONDA Page 43
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Win Runner Testing Modes
Context Sensitive
Context Sensitive mode records your actions on the application being tested in terms of the GUI objects you select (such as windows, lists, and buttons), while ignoring the physical location of the object on the screen. Every time you perform an operation on the application being tested, a TSL statement describing the object selected and the action performed is generated in the test script. As you record, Win Runner writes a unique description of each selected object to a GUI map.
The GUI map consists of files maintained separately from your test scripts. If the user interface of your application changes, you have to update only the GUI map, instead of hundreds of tests. This allows you to easily reuse your Context Sensitive test scripts on future versions of your application.
To run a test, you simply play back the test script. Win Runner emulates a user by moving the mouse pointer over your application, selecting objects, and entering keyboard input. Win Runner reads the object descriptions in the GUI map and then searches in the application being tested for objects matching these descriptions. It can locate objects in a window even if their placement has changed.
Analog
Analog mode records mouse clicks, keyboard input, and the exact x- and y-coordinates traveled by the mouse. When the test is run, Win Runner retraces the mouse tracks. Use Analog mode when exact mouse coordinates are important to your test, such as when testing a drawing application.
The Win Runner Testing Process
Testing with Win Runner involves six main stages:
1. Create the GUI Map
The first stage is to create the GUI map so Win Runner can recognize the GUI objects in the application being tested. Use the Rapid Test Script wizard to review the user interface of your application and systematically add descriptions of every GUI object to the GUI map. Alternatively, you can add descriptions of individual objects to the GUI map by clicking objects while recording a test.
SRTIST,NALGONDA Page 44
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
2. Create Tests
Next is creation of test scripts by recording, programming, or a combination
of both. While recording tests, insert checkpoints where we want to check the response of the application being tested. We can insert checkpoints that check GUI objects, bitmaps, and databases. During this process, Win Runner captures data and saves it as expected results—the expected response of the application being tested.
3. Debug Tests
Rerun tests in Debug mode to make sure they run smoothly. One can set breakpoints, monitor variables, and control how tests are run to identify and isolate defects. Test results are saved in the debug folder, which can be discarded once debugging is finished.
When Win Runner runs a test, it checks each script line for basic syntax errors, like incorrect syntax or missing elements in If, While, Switch, and For statements. We can use the Syntax Check options (Tools >Syntax Check) to check for these types of syntax errors before running your test.
4. Run Tests
Tests can be run in Verify mode to test the application. Each time Win Runner
Encounters a checkpoint in the test script, it compares the current data of the application being tested to the expected data captured earlier. If any mismatches are found, Win Runner captures them as actual results.
5. View Results
Following each test run, Win Runner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages.
If mismatches are detected at checkpoints during the test run, we can view the expected results and the actual results from the Test Results window. In cases of bitmap mismatches, one can also view a bitmap that displays only the difference between the expected and actual results.
We can view results in the standard Win Runner report view or in the Unified report view. The Win Runner report view displays the test results in a Windows-style viewer. The Unified report view displays the results in an HTML-style viewer (identical to the style used for Quick Test Professional test results).
SRTIST,NALGONDA Page 45
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
6. Report Defects
If a test run fails due to a defect in the application being tested, one can report information about the defect directly from the Test Results window.
This information is sent via e-mail to the quality assurance manager, who tracks the defect until it is fixed.
Using Win runner Window
Before you begin creating tests, you should familiarize yourself with the WinRunner main window.
To start Win Runner:
Choose Programs > Win Runner > Win Runner on the Start menu.
The first time you start Win Runner, the Welcome to Win Runner window and the “What’s New in Win Runner” help open. From the Welcome window you can create a new test, open an existing test, or view an overview of Win Runner in your default browser.
If you do not want this window to appear the next time you start Win Runner, clear the Show on Startup check box. To show the Welcome to Win Runner window upon startup from within Win Runner, choose Settings > General Options, click the Environment tab, and select the Show Welcome screen check box.
The Main Win Runner Window
The main Win Runner window contains the following key elements:
Win Runner title bar Menu bar, with drop-down menus of Win Runner commands
Standard toolbar, with buttons of commands commonly used when running a test
User toolbar, with commands commonly used while creating a test
Status bar, with information on the current command, the line number of the insertion point and the name of the current results folder
The Standard toolbar provides easy access to frequently performed tasks, such as opening, executing, and saving tests, and viewing test results.
Standard Toolbar
The User toolbar displays the tools you frequently use to create test scripts. By default, the User toolbar is hidden. To display the User toolbar, choose Window > User Toolbar. When you create tests, you can minimize the Win Runner window and work exclusively from the toolbar.
SRTIST,NALGONDA Page 46
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
The User toolbar is customizable. You choose to add or remove buttons using the Settings > Customize User Toolbar menu option. When you re-open Win Runner, the User toolbar appears as it was when you last closed it.
The commands on the Standard toolbar and the User toolbar are described in detail in subsequent lessons.
Note that you can also execute many commands using soft keys. Soft keys are keyboard shortcuts for carrying out menu commands. You can configure the soft key combinations for your keyboard using the Soft key Configuration utility in your Win Runner program group. For more information, see the “Win Runner at a Glance” chapter in your Win Runner User’s Guide.
Now that you are familiar with the main Win Runner window, take a few minutes to explore these window components before proceeding to the next lesson.
The Test Window
You create and run Win Runner tests in the test window. It contains the following
key elements:
Test window title bar, with the name of the open test Test script, with statements generated by recording and/or programming in TSL, Mercury
Interactive’s Test Script Language
Execution arrow, which indicates the line of the test script being executed during a test run, or the line that will next run if you select the Run from arrow option
Insertion point, which indicates where you can insert or edit text
SRTIST,NALGONDA Page 47
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Experiment 7:
Study of any web testing tool (e.g. Selenium)
Selenium is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
One of Selenium’s key features is the support for executing one’s tests on multiple browser platforms.
Selenium Components
Selenium is composed of three major tools. Each one has a specific role in aiding the development of web application test automation.
Selenium-IDE
Selenium-IDE is the Integrated Development Environment for building Selenium test cases. It operates as a Firefox add-on and provides an easy-to-use interface for developing and running individual test cases or entire test suites. Selenium-IDE has a recording feature, which will keep account of user actions as they are performed and store them as a reusable script to play back. It also has a context menu (right-click) integrated with the Firefox browser, which allows the user to pick from a list of assertions and verifications for the selected location. Selenium-IDE also offers full editing of test cases for more precision and control.
Although Selenium-IDE is a Firefox only add-on, tests created in it can also be run against other browsers by using Selenium-RC and specifying the name of the test suite on the command line.
Selenium-RC (Remote Control)
Selenium-RC allows the test automation developer to use a programming language for maximum flexibility and extensibility in developing test logic. For instance, if the application under test returns a result set, and if the automated test program needs to run tests on each element in the result set, the programming language’s iteration support can be used to iterate through the result set, calling Selenium commands to run tests on each item.
Selenium-RC provides an API (Application Programming Interface) and library for each of its supported languages: HTML, Java, C#, Perl, PHP, Python, and Ruby. This ability to use Selenium-RC with a high-level programming language to develop test cases also allows the automated testing to be integrated with a project’s automated build environment.
Selenium-Grid
SRTIST,NALGONDA Page 48
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Selenium-Grid allows the Selenium-RC solution to scale for large test suites or test suites that must be run in multiple environments. With Selenium-Grid, multiple instances of Selenium-RC are running on various operating system and browser configurations; Each of these when launching register with a hub. When tests are sent to the hub they are then redirected to an available Selenium-RC, which will launch the browser and run the test. This allows for running tests in parallel, with the entire test suite theoretically taking only as long to run as the longest individual test.
* Tests developed on Firefox via Selenium-IDE can be executed on any other supported browser via a simple Selenium-RC command line.
** Selenium-RC server can start any executable, but depending on browser security settings there may be technical limitations that would limit certain features.
Flexibility and Extensibility
Selenium is highly flexible. There are multiple ways in which one can add functionality to Selenium’s framework to customize test automation for one’s specific testing needs. This is, perhaps, Selenium’s strongest characteristic when compared with proprietary test automation tools and other open source solutions. Selenium-RC support for multiple programming and scripting languages allows the test writer to build any logic they need into their automated testing and to use a preferred programming or scripting language of one’s choice.
Selenium-IDE allows for the addition of user-defined “user-extensions” for creating additional commands customized to the user’s needs. Also, it is possible to re-configure how the Selenium-IDE generates its Selenium-RC code. This allows users to customize the generated code to fit in with their own test frameworks. Finally, Selenium is an Open Source project where code can be modified and enhancements can be submitted for contribution.
.Test Suites
A test suite is a collection of tests. Often one will run all the tests in a test suite as one continuous batch-job.
When using Selenium-IDE, test suites also can be defined using a simple HTML file. The syntax again is simple. An HTML table defines a list of tests where each row defines the filesystem path to each test. An example tells it all.
<html>
<head>
<title>Test Suite Function Tests – Priority 1</title> </head>
<body>
<table>
SRTIST,NALGONDA Page 49
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
<tr><td><b>Suite Of Tests</b></td></tr>
<tr><td><a href=”./Login.html”>Login</a></td></tr>
<tr><td><a href=”./SearchValues.html”>Test Searching for Values</a></td></tr>
<tr><td><a href=”./SaveValues.html”>Test Save</a></td></tr>
</table> </body>
</html>
A file similar to this would allow running the tests all at once, one after another, from the Selenium-IDE.
Test suites can also be maintained when using Selenium-RC. This is done via programming and can be done a number of ways. Commonly Junit is used to maintain a test suite if one is using Selenium-RC with Java. Additionally, if C# is the chosen language, Nunit could be employed. If using an interpreted language like Python with Selenium-RC than some simple programming would be involved in setting up a test suite. Since the whole reason for using Sel-RC is to make use of programming logic for your testing this usually isn’t a problem.
Few typical Selenium commands.
Open – opens a page using a URL.
Click/clickAndWait – performs a click operation, and optionally waits for a new page to load.
Verify Title/assert Title – verifies an expected page title.
VerifyTextPresent – verifies expected text is somewhere on the page.
VerifyElementPresent – verifies an expected UI element, as defined by its HTML tag, is present on the page.
Verify Text – verifies expected text and it’s corresponding HTML tag are present on the page.
Verify Table – verifies a table’s expected contents.
WaitForPageToLoad – pauses execution until an expected new page loads. Called automatically when clickAndWait is used.
Experiment 8:
Study of Any Bug Tracking Tool (Bugzilla)
SRTIST,NALGONDA Page 50
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Bugzilla is a “Bug Tracking System” that can efficiently keep track of outstanding bugs in a product. Multiple users can access this database and query, add and manage these bugs. Bugzilla essentially comes to the rescue of a group of people working together on a product as it enables them to view current bugs and make contributions to resolve issues.
Its basic repository nature works out better than the mailing list concept and an organized database is always easier to work with.
Advantage of Using Bugzilla:
1. Bugzilla is very adaptable to various situations. Known uses currently include IT support queues, Systems Administration deployment management, chip design and development problem tracking (both pre-and-post fabrication), and software and hardware bug tracking for luminaries such as Redhat, NASA, Linux-Mandrake, and VA Systems. Combined with systems such as CVS, Bugzilla provides a powerful, easy-to-use solution to configuration management and replication problems.
2. Bugzilla can dramatically increase the productivity and accountability of individual employees by providing a documented workflow and positive feedback for good performance. Ultimately, Bugzilla puts the power in user’s hands to improve value to business while providing a usable framework for natural attention to detail and knowledge store to flourish.
The bugzilla utility basically allows to do the following:
Add a bug into the database Review existing bug reports
Manage the content
Bugzilla is organised in the form of bug reports that give all the information needed about a particular bug. A bug report would consist of the following fields.
Product–>Component Assigned to
Status (New, Assigned, Fixed etc)
Summary
Bug priority
Bug severity (blocker, trivial etc)
Bug reporter
Using Bugzilla:
Bugzilla usage involves the following activities
SRTIST,NALGONDA Page 51
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Setting Parameters and Default Preferences Creating a New User
Impersonating a User
Adding Products
Adding Product Components
Modifying Default Field Values
Creating a New Bug
Viewing Bug Reports
Setting Parameters and Default Preferences:
When we start using Bugzilla, we’ll need to set a small number of parameters and preferences. At a minimum, we should change the following items, to suit our particular need:
▪ set the maintainer
▪ set the mail_delivery_method
▪ Set bug change policies
▪ set the display order of bug reports
To set parameters and default preferences:
1. Click Parameters at the bottom of the page. 2. Under Required Settings, add an email address in the maintainer field.
3. Click Save Changes.
4. In the left side Index list, click Email.
5. Select from the list of mail transports to match the transport we’re using. If evaluating a click2try application, select Test. If using SMTP, set any of the other SMTP options for your environment. Click Save Changes.
6. In the left side Index list, click Bug Change Policies.
7. Select On for commentoncreate, which will force anyone who enters a new bug to enter a comment, to describe the bug. Click Save Changes.
8. Click Default Preferences at the bottom of the page.
9. Select the display order from the drop-down list next to the When viewing a bug, show comments in this order field. Click Submit Changes.
SRTIST,NALGONDA Page 52
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Creating a New User
Before entering bugs, make sure we add some new users. We can enter users very easily, with a minimum of information. Bugzilla uses the email address as the user ID, because users are frequently notified when a bug is entered, either because they entered the bug, because the bug is assigned to them, or because they’ve chosen to track bugs in a certain project.
To create a new user:
1. Click Users. 2. Click add a new user.
3. Enter the Login name, in the form of an email address.
4. Enter the Real name, a password, and then click Add.
5. Select the Group access options. we’ll probably want to enable the following options in the row titled User is a member of these groups:
can confirm
edit bugs
edit components
6. Click Update when done with setting options.
Impersonating a User
Impersonating a user is possible, though rare, that we may need to file or manage a bug in an area that is the responsibility of another user when that user is not available. Perhaps the user is on vacation, or is temporarily assigned to another project. We can impersonate the user to create or manage bugs that belong to that user.
Adding Products
We’ll add a product in Bugzilla for every product we are developing. To start with, when we first login to Bugzilla, we’ll find a test product called TestProduct. We should delete this and create a new product.
To add a product:
1. At the bottom of the page, click Products. 2. In the TestProduct listing, click Delete.
3. Click Yes, Delete.
4. Now click Add a product.
SRTIST,NALGONDA Page 53
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
5. Enter a product name, such as “Widget Design Kit.”
6. Enter a description.
7. Click Add. A message appears that you’ll need to add at least one component.
Adding Product Components
Products are comprised of components. Software products, in particular, are typically made up of many functional components, which in turn are made up of program elements, like classes and functions. It’s not unusual in a software development team environment for different individuals to be responsible for the bugs that are reported against a given component. Even if there are other programmers working on that component, it’s not uncommon for one person, either a project lead or manager, to be the gatekeeper for bugs. Often, they will review the bugs as they are reported, in order to
redirect them to the appropriate developer or even another team, to review the priority and severity supplied by the reporter, and sometimes to reject bugs as duplicates or enhancement requests, for example.
To add a component:
1. Click the link add at least one component in the message that appears after creating a new product.
2. Enter the Component name.
3. Enter a Description.
4. Enter a default assignee. Use one of the users we’ve created. Remember to enter the assignee in the form of an email address.
5. Click Add.
6. To add more components, click the name of product in the message that reads edit other components of product <product name>.
Modifying Default Field Values
Once we begin to enter new bugs, we’ll see a number of drop-down lists containing default values. Some of these may work just fine for our product. Others may not. We can modify the values of these fields, adding new values and deleting old ones. Let’s take a look at the OS category.
To modify
To modify default field values:
1. At the bottom of the page, in the Edit section, click Field Values.
SRTIST,NALGONDA Page 54
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
2. Click the link, in this case OS, for the field we want to edit. The OS field contains a list of operating system names. We are going to add browsers to this list. In reality, we might create a custom field instead, but for the sake of this example, just add them to the OS list.
3. Click Add a value. In the Value field, enter “IE7.” Click Add.
4. Click Add a value again.
5. In the Value field, enter “Firefox 3.”
6. Click Add.
7. Where it reads Add other values for the op_sys field, click op_sys.
8. This redisplays the table. We should now see the two new entries at the top of the table. These values will also appear in the OS drop-down list when we create a new bug.
Creating a New Bug
Creating bugs is a big part of what Bugzilla does best.
To create a new bug:
1. In the top menu, click New. 2. If we’ve defined more than one component, choose the component from the component list.
3. Select a Severity and a Priority. Severity is self-explanatory, but Priority is generally assumed to be the lower the number, the higher the priority. So, a P1 is the highest priority bug, a showstopper.
4. Click the OS drop-down list to see the options, including the new browser names we entered.
5. Select one of the options.
6. Enter a summary and a description. We can add any other information of choice, but it is not required by the system, although we may determine that our bug reporting policy requires certain information.
7. Click Commit. Bugzilla adds our bug report to the database and displays the detail page for that bug.
Viewing Bug Reports
Eventually, we’ll end up with thousands of bugs listed in the system. There are several ways to view the bugs. The easiest is to click the My Bugs link at the bottom of the page. Because we’ve only got one bug reported, we’ll use the standard Search function.
To find a bug:
SRTIST,NALGONDA Page 55
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
1. Click Reports. 2. Click the Search link on the page, not the one in the top menu. This opens a page titled “Find
a Specific Bug.” Select the Status.
3. Select the Product.
4. Enter a word that might be in the title of the bug.
5. Click Search. If any bugs meet the criteria that we have entered, Bugzilla displays them in a list summary.
1. Click the ID number link to view the full bug report.
Modifying Bug Reports
Suppose we want to change the status of the bug. We’ve reviewed it and have determined that it belongs to one of the users we have created earlier
To modify a bug report:
1. Scroll down the full bug description and enter a comment in the Additional Comments field.
2. Select “Reassign bug to” and replace the default user ID with one of the other user IDs you created. It must be in the format of an email address.
Experiment 9:
Study of Any Test Management Tool ( Test Director)
Test Director is a global test management solution which provides communication, organization, documentation and structure to the testing project.
Test Director is used for
Mapping Requirements to User acceptance test cases Test Planning by placing all the test cases and scripts in it.
Manual testing by defining test steps and procedures
Test Execution status
Defect Management
The Test Director Testing Process
SRTIST,NALGONDA Page 56
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Test Director offers an organized framework for testing applications before they are deployed. Since test plans evolve with new or modified application requirements, you need a central data repository for organizing and managing the testing process. TestDirector guides through the requirements specification, test planning, test execution, and defect tracking phases of the testing process.
The Test Director testing process includes four phases:
Specifying Requirements
Requirements are linked to tests and defects to provide complete traceability and aid the decision-making process
See what percent of requirements are covered by tests
Each requirement in the tree is described in detail, and can include any relevant attachments. The QA tester assigns the requirement a priority level which is taken into consideration when the test team creates the test plan
Import from Microsoft Word or third party RM tool
Planning Tests
The Test Plan Manager enables to divide application according to functionality. Application can be divided into units, or subjects, by creating a test plan tree.
Define subjects according to:
o Application functionality-such as editing, file operations, and reporting
o Type of testing-such as functional, user interface, performance, and load
As the tests are also linked to defects, this helps ensure compliance with testing requirements throughout the testing process
Running Tests
As the application constantly changes, using test lab, run manual and automated tests in the project in order to locate defects and assess quality.
By creating test sets and choosing which tests to include in each set, test suite can be created? A test set is a group of tests in a Test Director project database designed to achieve specific testing goals.
Tests can be run manually or scheduled to run automatically based on application dependencies.
Tracking Defects
SRTIST,NALGONDA Page 57
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Locating and repairing application defects efficiently is essential to the testing process. Defects can be detected and added during all stages of the testing process. In this phase you perform the following tasks:
This tool features a sophisticated mechanism for tracking software defects, enabling Testing Team and the project Team to monitor defects closely from initial detection until resolution
By linking TestDirector to e-mail system, defect tracking information can be shared by all Development and Management Teams, Testing and Wipro Software Quality Assurance personnel
System Requirements for TestDirector
Server System configuration : 128 MB of RAM , 500 MB of free disk space, Win NT server, Win 2K server, IIS 5.0, MSAccess/Oracle 7.x,8.x,9/MS SQL Server
Client System configuration : 64 MB of RAM , 10 MB of free disk space, Win 95/98/NT/2K/XP, IE 5 , Netscape 4.7
Experiment 10:
Experiment : Study of any open source testing tool (TestLink)
Testlink is an open source test management tool. It enables creation and organization of test cases and helps manage into test plan. Allows execution of test cases from test link itself. One can easily track test results dynamically, generate reports, generate test metrics,prioritize test cases and assign unfinished tasks.
Its a web based tool with GUI, which provides an ease to develop test cases, organize test cases into test plans, execute these test cases and generate reports.
Test link exposes API, written in PHP, can help generate quality assurance dashboards. The functions like AddTestCase ToTestPlan, Assign Requirements,Create TestCase etc. helps create and organize test cases per test plan. Functions like GetTestCasesForTestPlan, GetLastExecutionResult allows one to create quality assurance dashboard.
SRTIST,NALGONDA Page 58
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
TestLink enables easily to create and manage Test cases as well as organize them into Test plans. These Test plans allow team members to execute Test cases and track test results dynamically, generate reports, trace software requirements, prioritize and assign tasks. Read more about implemented features and try demo pages.
Overall structure
There are three cornerstones: Product, Test Plan and User. All other data are relations or attributes for this base. First, definition of a couple of terms that are used throughout the documentation.
Products and Test Plans
Product: A Product is something that will exist forever in TestLink. Products will undergo many different versions throughout their life times. Product includes Test Specification with Test Cases and should be sorted via Keywords.
Test Plan: Test Plans are created when you’d like to execute test cases. Test plans can be
made up of the test cases of one or many Products. Test Plan includes Builds, Test Case Suite and Test Results.
User: An User has a Role, that defines available TestLink features.
Test Case Categorization
TestLink breaks down the test case structure into three levels Components, Categories, and test cases. These levels are persisted throughout the application.
Component: Components are the parents of Categories. Each Component can have many
Categories.
Category: Categories are the parents of test cases. Each Category can have many test cases.
Test Case: Test cases are the fundamental piece of TestLink.
Test Specification: All Components, Categories and test cases within Product.
Test Case Suite: All Components, Categories and test cases within Test Plan.
Test Specification
Creating Test Cases
SRTIST,NALGONDA Page 59
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Tester must follow this structure: Component, Category and test case. At first you create Component(s) for your Product. Component includes Categories. Category has the similar meaning but is second level of Test Specification and includes just Test Cases.
User can also copy or move Test Cases.
Test Cases has following parts:
• Title: could include either short description or abbreviation (e.g. TL-USER-LOGIN)
• Summary: should be really short; just for overview.
• Steps: describe test scenario (input actions); can also include precondition and cleanup
information here.
• Expected results: describe checkpoints and expected behaviour a tested Product or
system.
Deleting Test Cases
Test cases, Categories, and Components may be deleted from a test plan by users with lead permissions from the “delete test cases” screen. Deleting data may be useful when first creating a test plan since there are no results. However, Deleting test cases will cause the loss of all results associated with them. Therefore, extreme caution is recommended when using this functionality.
Requirements relation
Test cases could be related with software/system requirements as n to n. The functionality must be enabled for a Product. User can assign Test Cases and Requirements via link Assign Requirements in the main screen.
Test Plans
Test plan contains name, description, collection a chosen test cases, builds, test results, milestones, tester assignment and priority definition.
Creating a new Test Plan
Test Plans may be deleted from the “Create test plan” page (link “Create Test Plan”) by users with lead privileges. Test plans are the basis for test case execution. Test plans are made up of test cases
SRTIST,NALGONDA Page 60
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
imported from Products at a specific point of time. Test plans can only be created by users with lead privileges. Test plans may be created from other test plans. This allows users to create test plans from test cases that at a desired point in time. This may be necessary when creating a test plan for a patch. In order for a user to see a test plan they must have the propper rights. Rights may be assigned (by leads) in the define User/Project Rights section. This is an important thing to remember when users tell you they can’t see the project they are working on.
Test Execution
Test execution is available when:
1. A Test Specification is written.
2. A Test Plan is created.
3. Test Case Suite (for the Test Plan) is defined.
4. A Build is created.
5. The Test plan is assigned to testers (otherwise they cannot navigate to this Test Plan).
Select a required Test Plan in main page and navigate to the ‘Execute tests’ link. Left pane
serves for navigation in Test Case Suite via tree menu, filtering and define a tested build.
Test Status
Execution is the process of assigning a result (pass, fail, blocked) to a test case for a specific build. ‘Blocked’ test case is not possible to test for some reason (e.g. a problem in configuration disallows to run a tested functionality).
Insert Test results
Test Results screen is shown via click on an appropriate Component, Category or test case in navigation pane. The title shows the current build and owner. The colored bar indicate status of the test case. Yellow box includes test scenario of the test case.
SRTIST,NALGONDA Page 61
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Updated Test Cases: If users have the proper rights they can go to the “Update modified test case” page through the link on main page. It is not necessary for users to update test cases if there has been a change (newer version or deleted).
Example of TestLink workflow:
1. Administrator create a Product “Fast Food” and a user Adam with rights “leader” and Bela with rights “Senior tester”.
2. Adam imports Software Requirements and for part of these requirements generates empty Test cases.
3. Bela describe test sneario of these Test cases that are organized according to Components and Categories.
4. Adam creates Keyword: “Regression” and assignes this keyword to ten of these test cases.
5. Adam creates a Test Plan “Fish & Chips”, Build “Fish 0.1” and add Test Cases with keywords “Regression”.
6. Adam and Bela execute and record the testing with result: 5 passed, 1 failed and 4 are blocked.
7. Developers make a new build “Fish 0.2” and Bela tests the failed and blocked test cases only. Exceptionaly all these five Test cases passed.
8. Manager would like to see results. Administrator explain him that he can create account himself on the login page. Manager do it. He has “Guest” rights and could see results and Test cases. He can see that everything passed in overal report and problems in build “Fish 0.1” in a report for particular Build. But he can change nothing.
Experiment: 11
Write a test report document for a library system
1.Introduction
1.1. PurposeThe main objective of this document is to illustrate the requirements of the project Library Management system. The document gives the detailed description of the both functional and non functional requirements proposed by the client. The document is developed after a number of consultations with the client and considering the complete requirement specifications of the given Project. The final product of the team will be meeting the
SRTIST,NALGONDA Page 62
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
requirements of this document.1.2. Scope of the projectThe system accepts the General Library Transactions of book like issue, return and renewals for the members . The different areas where we can use this application
• Any education institute can make use of it for providing information about author, content of the available books.• It can be used in offices and modifications can be easily done according to requirements.1.3. Conventions UsedThe following are the list of conventions and acronyms used in this document and the project as well:• Administrator: A login id representing a user with user administration privileges to the software .• User: A general login id assigned to most users• Client: Intended users for the software• SQL: Structured Query Language; used to retrieve information from a database .• SQL Server: A server used to store data in an organized format .• Unique Key: Used to differentiate entries in a database .2. Overall Description2.1. Product PerspectiveThe proposed Library Management System will provide a search functionality to facilitate the search of resources. This search will be based on various categories viz. book name . Also Advanced Search feature is provided in order to search various categories simultaneously. Further the library staff personnel can add/update/remove the resources and the resource users from the system.2.2. Product FeaturesThere are two different users who will be using this product:• Librarian who will be acting as the administrator• Student of the University who will be accessing the Library online.The features that are available to the Librarian are:• A librarian can issue a book to the student• Can view The different categories of books available in the Library .• Can view the List of books available in each category• Can take the book returned from students• Add books and their information of the books to the database• Edit the information of the existing books.• Can check the report of the issued Books.• Can access all the accounts of the students.The features available to the Students are:• Can view The different categories of books available in the Library• Can view the List of books available in each category
SRTIST,NALGONDA Page 63
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
• Can own an account in the library• Can view the books issued to him• Can put a request for a new book• Can view the history of books issued to him previously• Can search for a particular book.2.3. Technologies used• SQL server• JAVA• MS-Access Database
Viva Questions and answers
1. Why testing..?
Ans: the purpose of the testing is to show the software works, to a how software doesn’t work, to reduce the perceived risk of not working, to an acceptable value.
2. Wht is purpose of the debugging.?
Ans : to find an error or misconception that lead to the program failure and to design and implement the program changes that correct an error
SRTIST,NALGONDA Page 64
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
3. What is testing?
Ans : to show that a program has bugs
4. What is the function-testing.?
Ans : in function testing the program treated as a black box.it is subjected to inputs and its outputs are verified for conformance to specified behavior
5. What is a structural testing ?
Ans : structural testing does look at the implementation details such thing as programming style control methods source language ,data base design and coding details dominat structural testing.
6. What is builder ?
Ans : who designs for and is accountable to buyer.
7. What is module?
Ans : the module is a descreate , well defined small component of a system .
8. Who is tester ?
Ans :who is dedicated to builders destruction and operator
9. What is unit testing ?
Ans : it is testing is used to show that the unit does not satisfy its functional specification or that implemented structure does not match the intended design structure
10. What is component testing ?
Ans : this testing is used to show the component does not satisfy its functional specification or that implemented structure does not match the intended design structure
11. What is Integration testing ?
Ans : this testing is used to show that even though the components were individually satisfactory as demonstrated by successful passage of component tests , the combination of component are incorrect or inconsistent.
12. What is system testing ?
SRTIST,NALGONDA Page 65
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Ans : system testing is aimed at revealing bugs that cannot be attributed to components as such to , the inconsistencies between components , or to the planed interaction of components and other objects.
13. What are the parts of data specification?
Ans : contents , structure , and attributes.
14. What is path testing ?
Ans : path testing is the name given to a family of test techniques based on judiciously selecting a set of test paths through the program
15. Define predicates?
Ans :the logical function evaluated at a decision is called predicate
16. What is control flow graph?
Ans : it is a graphical representation of a programs control structure
17. what is path sensitizing ?
Ans:the act of finding a set of solutions to the path predicate expression is called path sensitizing
18. what is trasaction ?
Ans : its is a unit of work seem from a system users point of view.
19. What are the transaction flow testing flow testing techniques?
Ans : 1.get the transaction flows.
2. Inspections, reviews, work troughs
3. Path selection.
4. Sensitization
5. Instrumentation.
6. Test databases.
7. execution.
20. what is data flow testing ?
SRTIST,NALGONDA Page 66
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Ans : data flow testing uses the control flow to explore the un reasonable things that can happen to data.
21.What is domain testing?
Ans : A testing which can be based on specification or equivalent implementation information.
22. What is interior point?
Ans : An interior point is a point in the domain such that all points within an arbitrarily small distance (called an epsilon neighborhood) are also in the domain.
23. What is boundary point?
Ans : A boundary point is one such that within an epsilon neighborhood there are points both in the domain and not in the domain.
24.What is extreme point ?
Ans : An extreme point is a point that does not lie between any two other arbitrary but distinct points of a (convex) domain.
25.What is path expression?
Ans : An algebraic representation of sets of paths in a graph is called a
26.What is link weight ?
Ans : A letter or a sequence of letters that denote the sequence of data-flow actions on a linkis called
27. What is regular expression ?
Ans : With suitable arithmetic laws and weights, path expressions are converted intoalgebraic functions that are called regular expressions.
28.What is cross term step?
Ans : The fundamental step of the reduction algorithm for converting a flow graph into apath expression is called cross term step.
29. What is star mesh transformation?
SRTIST,NALGONDA Page 67
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
Ans : The cross-term step of the reduction algorithm for converting a flow graph into pathexpressions is also called as
30. What is structured flow graph?
Ans : A flow graph that can be reduced to a single link by successive application oftransformations is called
31.An equivalence relation satisfies which properties..?
Ans : reflexive, transitive, symmetric
32.Which theorem that is proposed on regular expressions?Ans : Huang's theorem
33. KV chart is an abbreviation forAns: Karnaugh-Veitch chart
34. Knowledge-based system is also known as
Ans : expert system
35. what is inference engine ?Ans :the processing of a knowledge in an expert system is done by a program called inference engine
36. What is default rule ?Ans : A rule that specifies the default action to be taken when all other rules fail in adecision table is called default rule
37. What is prime implecant ?Ans : Each product term in a simplified version of the sum of products form in Booleanalgebra is called prime implicant
38. What is condition testing? Ans : A list of names of conditions in a decision table is called condition stub
39. What is action stub?
Ans : the list of names the actions the routine will take or initiate if the rule is satisfied is called action stub
40. What is state testing?Ans : here we are going to fine out wrong number of states ,wrong transition for giving state input combination, and wrong output for giving transition
SRTIST,NALGONDA Page 68
Case Tools & Software Testing Lab IV B.Tech I Sem (R09)
41. What is regression testing?Ans : it is a any type of software testing that seeks to uncover no errors or regressions in existing functionality after changes have been made by a system
42. What is use for partitionaning algorithm? Ans: it is used for converting graphs with loops into loop free graphs of equivalence classes
43. What is diagonal matrix?Ans : A square array with one row and one column for every node in the graph is called a diagonal matrix
44. What is undirected graph?Ans : A graph whose relations are symmetric is called a undirected graph
45. What is decision table describing?Ans: The control logic of a combinational program can be described by decision table.
46. What is predicate?
Ans : A combinational machine selects paths based on the values is called predicates
47. What are the properties of relations?
Ans:transitive , reflexive, symmentric
48.What is dead state ?
Ans: A state that once entered cannot be left is called dead state
49.What is unreachable state ? Ans: A state that no input sequence can reach is called unreachable state
50.What is finite state machine ? Ans: An abstract device that can be represented by a state graph having a finite
number of states and a finite number of transitions between states
SRTIST,NALGONDA Page 69
Top Related