STV Lab Final Yr

Software Testing and Case Tools Lab
LAB OBJECTIVE
 Overview of UML
 Basic & Advanced Models
 Class , Object, Collaboration & Sequence
 Use Cases Advanced Modeling
 Component Diagram & Deployment Diagrams
INTRODUCTION ABOUT LAB
There are 66 systems (Compaq Presario) installed in this Lab. Their

configurations are as follows:
Processor : AMD Athelon ™ 1.67 GHz
RAM : 256 MB
Hard Disk : 40 GB
Mouse : Optical Mouse
Network Interface card : Present
Software
 All systems are configured in DUAL BOOT mode i.e., Students can boot from Windows
XP or Linux as per their lab requirement.
This is very useful for students because they are familiar with different Operating
Systems so that they can execute their programs in different programming
environments.
 Each student has a separate login for database access
Oracle 9i client version is installed in all systems. On the server, account for each
student has been created.
This is very useful because students can save their work ( scenarios’, pl/sql
programs, data related projects ,etc) in their own accounts. Each student work is safe and
secure from other students.
 Latest Technologies like DOT NET and J2EE are installed in some systems.
Before submitting their final project, they can start doing mini project from 2nd year
onwards.
 MASM ( Macro Assembler ) is installed in all the systems
Students can execute their assembly language programs using MASM. MASM is
very useful students because when they execute their programs they can see
contents of Processor Registers and how each instruction is being executed in the
CPU.
 Rational Rose Software is installed in some systems
Using this software, students can depict UML diagrams of their projects.
 Softwares installed: C, C++, JDK1.5, MASM, OFFICE-XP, J2EE and DOT NET,
Rational Rose.
 Systems are provided for students in the 1:1 ratio.
 Systems are assigned numbers and same system is allotted for students when they
do the lab.
Guidelines to Students
1. Learn what the UML is, what it is not and why it is relevant to the process of developing software-
intensive systems
2. Master the vocabulary rules and idioms of the UML and in general how to speak the language
efficiently
3. Under stand how to apply UML to Solutionve a number of common problems
The user guide provides a reference to the use of specific UML features, However it is not
intended to be a comprehensive reference manual for UML. That is focus on other book, The
Unified Modeling Language Reference Manual
For the developer approaching the UML for the first time, the user guide is best-read
linearly. All chapters are constructed so that each builds upon the contents of previous one, thus
lending it as linear progression.
UML Syllabus Programs (JNTU)
S. No Programs
1. ATM system
a. Class diagram for ATM.
b. Use case diagram for ATM.
c. Activity diagram for ATM
d. Sequence diagram ATM
e. Collaboration diagram for ATM
f. Component diagram for ATM
g. Deployment diagram for ATM
h. State Transition diagram for ATM
2. Library Management System
a. Class diagram for LMS
b. Use case diagram for LMS
c. Activity diagram for LMS
d. Sequence diagram LMS
e. Collaboration diagram for LMS
f. Component diagram for LMS
g. Deployment diagram for LMS
h. State Transition diagram for LMS
3. Flight Reservation System
a. Class diagram for FRS
b. Use case diagram for FRS
c. Activity diagram for FRS

d. Sequence diagram FRS
e. Collaboration diagram for FRS
f. Component diagram for FRS
g. Deployment diagram for FRS
h. State Transition diagram for FRS

Description about UML
1. Model
 A model is a simplification of reality.
 A model provides the blueprints of a system.
 A model may be structural, emphasizing the organization of the system,
or it may be behavioral, emphasizing the dynamics of the system.
 We build models so that we can better understand the system we are
developing.
 We build models of complex systems because we cannot comprehend
such a system in its entirety.
Through modeling, we achieve four aims.
 Models help us to visualize a system as it is or as we want it to be.

 Models permit us to specify the structure or behavior of a system.
 Models give us a template that guides us in constructing as system.
 Models document the decisions we have made
2. Principles of Modeling
 The choice of what models to create has a profound influence on how

a problem is attacked and how a Solutionution is shaped
 Every model may be expressed at different levels of precision
 The best models are connected to reality
 No single model is sufficient. Every nontrivial system is best
approached through a small set of nearly independent models
3. Unified Modeling Language (UML)
The UML is a language for
 Visualizing
 Specifying
 Constructing
 Documenting
The UML is a Language

 A modeling language is a language whose vocabulary and

rules focus on the conceptual and physical representation of
a system
The UML is a Language for Visualizing
 Some programmers think of an implementation and then

code it. Some programmers think mentally i.e. they even
sketch out a few ideas on a paper. That means some things
are best modeled textually, others are best modeled
graphically. The UML is such a graphical language.
The UML is a Language for Specifying
 Specifying means building models. It specifies of all the

important analysis, design, and implementation decisions
that must be made in developing a software project.
The UML is a Language for constructing
 The UML is not a visual programming language, but its

models can be directly connected to a variety of a
programming language. This means that it is possible to
map from a model in the UML to a programming language
such as Java, C++.
The UML is a Language for Documenting
 A Healthy software organization produces all sorts of

artifacts in addition to raw executable code. These artifacts
include
1. Requirements
2. Architecture
3. Design
4. Source code
5. Project plans
6. Tests
7. Releases
 The UML addresses the documentation of a system’s

architecture and all of its detail
4. Architectural views of UML
The user model view
- Use Case Diagram - The functionality of a system
The structural model view
- Class Diagram - The static structure of a system
- Object Diagram - The static structure of a system at a particular time
The behavioral model view
- Sequence Diagram - Interaction among elements of a system in a time sequence
- Collaboration diagram - Interaction among elements and their relations organized

in time and space
- State Diagram - The status condition and responses of the elements of a system
- Activity Diagram - The activities of the system
The implementation model view
- Component Diagram - The organization of the elements realizing the system
The Environment model view
- Deployment diagram - Configuration of environment elements and the mapping of elements

realizing the system into them
1.ATM system
Aim: UML software is designed for supporting from a computer ATM banking network.
Solutionution: All the process involves in the bank is computerized in the state. All accounts are
maintained in the bank and also the transaction affected including ATM transactions at the
process by the computers in the bank.
An AT M accepts a relevant cash card, interacts with the user, communicates with the
central system, carry out the transaction, dispenses cash and then print receipts. The system
designed and implemented must include appropriate record keeping and security provisions the
system must have concurrent access to the same account.
Diagrams:
1. Class diagram.
2. Use case diagram.
3. Activity diagram.
4. Sequence diagram.
5. Collaboration diagram.
6. Component diagram.
7. Deployment diagram.
8. State transition diagram.

1. ATM scenario for class diagram.

2. ATM scenario for Use-Case diagram.
Bank officer
Change pin Transfer fund
Deposit funds
Customer Make payment
Client
Withdraw money View balance
Transfer funds
3. ATM scenario for activity diagram.
Insert
card
Enter
PIN
Connect Not connected
Enter
transition
Any more transaction
No more transaction
Remove
card
4. ATM scenario for Sequence diagram.
A : Atm ac : B : Bank
machine account client
1: Insert card
Insert PIN
3 : Enter PIN
4 : Verification
5 : PIN ok
6 : Request for transaction
7 : Process transaction
8 : Enter amount
9 : Amount entered
10 : Withdrawal
11 : Withdrawal success
12 : Dispense cash
13 : take cash
14 : Terminate
15 : Print slip
16 : Eject card
5. ATM scenario for Collaboration diagram.

6. ATM scenario for Component diagram.
ATM.exe
Card Reader Cash Dispenser
Card Reader ATM Screen Card dispenser
ATM Screen
7.ATM Scenario for Deployment Diagram

8. ATM Scenario State Transition Diagram

Library Management System
Aim: To model the Library management system by using UML diagrams.
Solutionution: a system lends books and magazines to members who are registered in the
system .A member can reserve a book, receive and return a book by the person from the library.
Diagrams:
1. Class diagram.
1. Class diagram for Librarian scenario.

2. Use-case diagram for Librarian scenario.
Purchase
Register
Lends
Reserve
Librarian1 User1
Update
Take
Reservation Return
3. Activity diagram for Librarian scenario
User_id
valid
Register
Carry operation
repeat
Log out
4. Sequence diagram for Librarian scenario.
User Librarian Data base
User id
Check
Valid
Register
Not available
Receive
Lend
Return
Update
5. Collaboration diagram for Librarian scenario.
1.User id
2.Register
3.Receive
8.Return
User Librarian
7.Take
4.Valid 2.checks
5.Not 9.Update
Data base
6. Component diagram for Librarian scenario.
Librarian
Student
Borrow_books
7. Deployment diagram for Librarian scenario.
Does
updation ...
Admin
Book
Aplies for
b...
registrat...
Student
Provides
b...
8. State Transition diagram.
Delivered to end user Delivered
Dispatch courier Dispatched
Undelivered
Indicates
start o... No one at house
Indicates end
of a st...
Flight Reservation System.
Aim: To model the Flight Reservation System by using UML diagrams.
Solutionution:: A member can reserve a fight tickets, to specify their boarding and
destination place of passengers (adult & children) and date of travel.
Diagrams:
1. Class diagram.

1.Class diagram for flight scenario.

1. Use-case diagram for flight scenario.
<<auto cancel>>
manage a reservation
credit card provider

clock
make a reservation
check-in passanger
reservation maker
enter claim for lost baggage
baggage agent
manage claim for lost baggage

2. Activity diagram for flight scenario.
passenger ground crew air craft
make
reservation
auto fuel
prepare cargo
hold
check-in
pilot check
bags checked stow baggage
file flight plan
board plane
close main
door
3.Sequence diagram for flight scenario.
passanger reservation reservation destination

system manager
1.make reservation()
2.enter PIN() 3.verify PIN()
4.valid()
5.ask for destination()
6.destination()
7.destination() 8.show flights
3. Component diagram for flight scenario.
passang flight
er
ticket
4. Deployment diagram for flight scenario.
MS
Access
reserve
ticket
flight flight
details status
5. State transition diagram for flight scenario.
purchased
price change (today=expiry date)
price change
(today<expiry date) excersible
begining of expiry date
knocked-in
exercise/exercise
end of expiry date/expire

References
Books / Material
Text Books
Grady Booch, James Rumbaugh, Ivar Jacobson : The Unified Modeling Language User Guide,
1.
Pearson Education.
Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado: UML 2 Toolkit,
2.
WILEY-dreamtech India Pvt. Ltd.
Suggested / Reference Books
1) Meilir Page-Jones : Fundamentals of Object Oriented Design in UML, Pearson Education
2) Atul Kahate: Object Oriented Analysis & Design, The McGraw-Hill Companies
3) Mark Priestley: Practical Object-Oriented Design with UML,TATA McGrawHill
Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process,
4)
Pearson Education
Web sites
1) http://en.wikipedia.org/wiki/Unified_Modeling_Language
2) http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/index.htm
SOFTWARE TESTING LAB

PART II
SOFTWARE TESTING
OBJECTIVES OF THE LAB
1. Testing is a process of executing a program with the intent of finding an error.
2. A good test case is one that has a high probability of finding an as yet undiscovered error.
3. A successful test is one that uncovers an as yet undiscovered error.
4. Understand the purpose of testing while producing the software project
5. Understand how to use WinRunner,
6. Understand how to use QTP
7. Understand how to use Bugzilla,Test Director,Test Link
REQUIREMENTS
System configuration :
128 MB of RAM , Win NT server, Win 2K server, IIS 5.0, MSAccess/Oracle 7.x,8.x,9/MS SQL
,WinRunner Tool,
Selenium Tool,
Test Director,
Bugzilla,
Test Link,
QTPTool.
LAB SYLLABUS PROGRAMS (JNTU)
Testing Lab List of Experiments
1. Write programs in „C‟ Language to demonstrate the working of the following a. constructs: i)
do...while ii) while….do iii) if…else iv) switch v) for
2. ―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.
3. Take any system (e.g. ATM system) and study its system specifications and report the various bugs
4. Write the test cases for any known application (e.g. Banking application)
5. Create a test plan document for any application (e.g. Library Management System)
6. Study of any testing tool (e.g. Win runner)
7. Study of any web testing tool (e.g. Selenium)
8. Study of any bug tracking tool (e.g. Bugzilla, bugbit)
9. Study of any test management tool (e.g. Test Director)
10. Study of any open source-testing tool (e.g. Test Link)
11.Study of QTP testing tool

Ex-1:Write programs in ‘C’ Language to demonstrate the working of the following

constructs:
i) do...while ii) while….do iii) if…else iv) switch v) for
Solution:
// WHILE LOOP
#include<stdio.h>
int main()
{
int n,i=1,sum=0;
printf("ENTER THE VALUE OF N:");
scanf("%d",&n);
printf("First %d numbers are\n",n);
while (i<=n)
{
printf("%7d ",i); //%7 to print the digit within 7 slots
sum = sum +i;
i++;
}
printf("\nSum = %d\n",sum);
return 0;
}
// DO WHILE LOOP
#include<stdio.h>
int main ()
{
int n,i=1,sum=0;
scanf("%d",&n);
do
{
printf("%d,",i);
sum=sum+i;
i++;
}
while(i<=n);
printf("\n\nSum=%d\n",sum);
return 0;
}
//FOR LOOP
#include<stdio.h>
int main()
{
int n,i=1,sum=0;
scanf("%d",&n);
for(i=1;i<=n;i++)
{
printf("%7d",i);
sum=sum+i;
}
printf("\n\nSum = %d",sum);
return 0;
}
//Switch Case:
#include<stdio.h>
#include<stdlib.h>
void main()
{
int a,b,res,ch;
printf("\t *********************");
printf("\n\tMENU\n");
printf("\t********************");
printf("\n\t(1)ADDITION");
printf("\n\t(2)SUBTRACTION");
printf("\n\t(3)MULTIPLICATION");
printf("\n\t(4)DIVISION");
printf("\n\t(5)REMAINDER");
printf("\n\t(0)EXIT");
printf("\n\t********************");
printf("\n\n\tEnter your choice:");
scanf("%d",&ch);
if(ch<=5 & ch>0)
{
printf("Enter two numbers:\n");
scanf("%d%d",&a,&b);
}
switch(ch)
{
case 1:
res=a+b;
printf("\n Addition:%d",res);
break;
case 2:
res=a-b;
printf("\n Subtraction:%d",res);
break;
case 3:
res=a*b;
printf("\n Multiplication:%d",res);
break;
case 4:
res=a/b;
printf("\n Division:%d",res);
break;
case 5:
res=a%b;
printf("\n Remainder:%d",res);
break;
case 0:
printf("\n Choice Terminated");
exit(1);
break;
default:
printf("\n Invalid Choice");
}
}
Out Put
Result: In the above programs while,do—while,for programs aim is to give sum of

first
10 numbers is 55.Our output is matched with the actual result. So testcase is
passed.
In switch case program the addition case sum of 3 and 5 is 8.Our result is matched
with
actual result So testcase is passed.
Ex:2 “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.
SOLUTION:
include<stdio.h>
void main()
int m,n,p,q,c,d,sum=0;
int first[1000][1000],second[10],multiply[10][10];
clrscr();
printf("enter the number of rows and columns of first matrix\n"));
scanf("%d%d ‘,&m,&n);
printf("enter the elements of first matrix\n");
for(c=0;c<m;c++);
for(d=0;d<n;d++)
scanf("%d",&first[c][d));
printf("enter the number of rows and columns of second matrix\n");
scanf("%d%d",&p,&q);
if(n!=p)
printf("matrices with entered orders can't be multiplied with each other\n");
else
printf("enter the elements of second matrix\n")

for(c=0;c<p;c++)
for(d=0;d<q;d++)
scanf("%d",&second[c][d]);
for(c=0;c<m;c++)
for(d=0;d<q;d++)
for(k=0;k<p;k++)
sum=sum+first[c][k]*second[k][d];
multiply[c][d]=sum;
sum=0;
print("product of entered matrices:\n");
for(c=0;c<m;c++)
for(d=0;d<q;d++);
printf("%d\t",multiply[c][d]);
printf("\n");
}
REASONS FOR FAILURE OF MATRIX MULTIPLICATION:
1. In the program array size is given as 1000 then the bug as “Array Size too
Large”. So Matrix Multiplication Fails.
2. In the program ‘;’ is missed so bug is ” Statement missing ;”.
3. In the program we entered “ ’ ” in place of ‘ “ ‘ then the bug as “Expression
Syntax” and “Unterminated String or character constant”.
4. The bug “Invalid indirection” comes when we miss array size of matrix [10].
5. The bug “Declaration Syntax error” when we miss # in header file.
6. The bug “Code has no Effect” when we took ‘)’ in place of ’]’.
7. When we kept “VOID MAIN “ then it returns as a warning of “void
functions may not return a value”.
8. When we insert an extra symbol of ‘)’ then it has a bug of “statement
missing ;”.
9. Then runtime error is found when give “print” in place of “printf” as shown
Undefined symbol –print in module MATRIXMUL.C
10.The bug “Undefined symbol ‘k’” when missed k in the declaration.
11.The program output when the two matrices are as follows
Enter first matrix no.of rows and columns 2 3
Enter second matrix no.of rows and columns 2 3
Then the bug as”Matrices with entered orders can’t be multiplied with each
other”.
Ex:3 Take any system (e.g. ATM system) and study its system specifications and
report the various bugs.
Solution:
The software to be designed will control a simulated automated teller
machine (ATM) having a magnetic stripe reader for reading an ATM card, a
customer conSolutione (keyboard and display) for interaction with the customer, a
slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer
for printing customer receipts, and a key-operated switch to allow an operator to
start or stop the machine. The ATM will communicate with the bank's computer
over an appropriate communication link. (The software on the latter is not part of
the requirements for this problem.)
The ATM will service one customer at a time. A customer will be required
to insert an ATM card and enter a personal identification number (PIN) - both of
which will be sent to the bank for validation as part of each transaction. The
customer will then be able to perform one or more transactions. The card will be
retained in the machine until the customer indicates that he/she desires no further
transactions, at which point it will be returned - except as noted below. The ATM
must be able to provide the following services to the customer:
 A customer must be able to make a cash withdrawal from any suitable

account linked to the card, in multiples of $20.00. Approval must be
obtained from the bank before cash is dispensed.
 A customer must be able to make a deposit to any account linked to the
card, consisting of cash and/or checks in an envelope. The customer will
enter the amount of the deposit into the ATM,
subject to manual verification when the envelope is removed from the
machine by an operator. Approval must be obtained from the bank before
physically accepting the envelope.
 A customer must be able to make a transfer of money between any two
accounts linked to the card.
 A customer must be able to make a balance inquiry of any account linked to
the card.
 A customer must be able to abort a transaction in progress by pressing the
Cancel key instead of responding to a request from the machine.
The ATM will communicate each transaction to the bank and obtain
verification that it was allowed by the bank. Ordinarily, a transaction will be
considered complete by the bank once it has been approved. In the case of a
deposit, a second message will be sent to the bank indicating that the customer has
deposited the envelope. (If the customer fails to deposit the envelope within the
timeout period, or presses cancel instead, no second message will be sent to the
bank and the deposit will not be credited to the customer.)If the bank determines
that the customer's PIN is invalid, the customer will be required to re-enter the
PIN before a transaction can proceed. If the customer is unable to successfully
enter the PIN after three tries, the card will be permanently retained by the
machine, and the customer will have to contact the bank to get it back.
If a transaction fails for any reason other than an invalid PIN, the ATM will
display an explanation of the problem, and will then ask the customer whether
he/she wants to do another transaction.
The ATM will provide the customer with a printed receipt for each successful
transaction, showing the date, time, machine location, type of transaction,
account(s), amount, and ending and available balance(s) of the affected account
("to" account for transfers).
The ATM will have a key-operated switch that will allow an operator to start
and stop the servicing of customers. After turning the switch to the "on" position,
the operator will be required to verify and enter
the total cash on hand. The machine can only be turned off when it is not servicing
a customer. When the switch is moved to the "off" position, the machine will shut
down, so that the operator may remove deposit envelopes and reload the machine
with cash, blank receipts, etc.
The ATM will also maintain an internal log of transactions to facilitate
reSolutionving ambiguities arising from a hardware failure in the middle of a
transaction. Entries will be made in the log when the ATM is started up and shut
down, for each message sent to the Bank (along with the response back, if one is
expected) for the dispensing of cash, and for the receiving of an envelope. Log
entries may contain card numbers and dollar amounts, but for security will never
contain a PIN.
Various Bugs in ATM System
Bug Priority:
World Web dictionary defines the word “Priority” as - Status established in order
of importance or urgency. Priority of a defect/bug tells us how soon it is required
to fix the problem. Priority reflects a business decision as to how soon that bug
should be fixed. Priority of the bug determines what gets fixed next and what does
not. The priority of a bug can be decided from either the Project management point
of view or from the user’s point of view. A bug that is of high priority from the
Project management point of view may or may not be of high priority if assessed
from the user’s point of view. Check with your users; their prioritizations may
surprise you! Priority of a bug can be classified as:
P1 – FIX the bug ASAP before the release, preferably in the current development
iteration itself.
P2 – The Bug can be fixed in the successive iteration. But the fix must be done
before the next major release of the Product.
P3 – The bug can be left to be fixed in the subsequent releases.
P4 – There is no hurry. This bug can be fixed as and when time permits.
Bug Severity Vs. Bug Priority:

The severity of a bug does not necessarily translate into the urgency to fix it. A
severe bug that crashes the application only once on a Feb 29th (leap year) for
0.0001% of the users is lower priority than a mishandled error condition resulting
in the need to re-enter a portion of the input for every user every time. Many bugs
cause crashes, but aren't fixed because the crash is very infrequent or on a
version/platform/feature low on the vendor's support list. Corner-case crashes,
crashes that are dependent on a rare combination of sequence of events (trigger to
set off the crash) fall under such classification of low priority bugs. Once I was
testing the Parser of my application. And the Parser used to crash when the
parameters were: 'MaxNulls' = '999999999' and 'MaxPrefixes' = '999999999'. This
was a catastrophic crash, which was causing the Program to terminate. However, it
took almost 2 years to get this crash fixed as it was rated with a low Priority
(despite of its high severity) for obvious reason! :)
ATM Machine Example!

Let’s take the example of an ATM machine to further understand the different
possible combinations of bug severity and priority:
Low Severity and High Priority Bug: Suppose you are testing an ATM machine
and you notice that the welcome screen displays a misspelled Bank name! (e.g. in
place of “Welcome to ICICI Bank” it rather displays “Welcome to UCICI Bank”.
This is quite possible, considering the fact that the letters “U” and “I” share close
neighborhood in a typical QWERTY type keyboard). This might be a cosmetic
error and would not hamper the functioning of the ATM machine in any possible
way; still this could prove to be a real pain in the eyes for a customer. Considering
that the spelling error is in a frequently used part of the program, it might give an
overall bad impression that could hurt the Bank’s reputation. These kinds of bugs
are real annoyance for the customers and no Bank would want to loose revenue for
a silly error like this one. So though this bug is of low severity, its priority would
be high for obvious reasons. It is quite interesting that often, low severity cosmetic
errors like these get a high priority.
High Severity and Low Priority Bug: Think of a bug that cause the ATM
machine to black out if an user tries to use an expired ATM card and try it for 13
consecutive times (even after the machine keeps rejecting it)! Sounds like a critical
crash? Well, it might be a critical bug as far as its severity is concerned, but don’t
be too surprised if you see a low Priority being assigned to it. Reason? I think its
obvious!
High Severity and High Priority Bug: These kinds of bugs are easier to imagine.
Any kind of bug that results in some major catastrophic failure (crashes, system
hang, memory corruptions, data loss, functionalities that does not work and so on)
and that occurs in areas of the application that are frequently used can be classified
under such types of high severity and high priority bugs. Think of scenarios where
the ATM machine - does not detect a valid card even after entering correct PIN
number, hangs if tried with an invalid card and/or PIN number, blocks the card
after just 1 unsuccessful entry of PIN (instead of 3 wrong entries), does not
dispense money even if there is sufficient cash in the a/c and in the ATM machine,
dispenses incorrect amount to the user, does not forget the previous session even
after the transaction is complete (in case of ATM machines where you have to
swipe your card instead of inserting it), does not return the card even after the
transaction is complete and so on. As you can imagine all of these cases of bugs
can fall under high severity and high priority type.
Low Severity and Low Priority Bug: These are often low impact low on
urgency-meter bugs that are quite harmless and can be fixed without a hurry. These
kind of bugs do not harm the application in a disastrous way and the chance of an
end user/customer being annoyed by it is also very less. Think of a scenario where
the ATM machine does not append a title (Mr/Miss/Mrs) to the name of the
customer in the welcome screen. This would not affect the business in a drastic
way. And there might not be many customers who would mind it if their name is
displayed without a title.
Ex-4:
AIM: Write the test cases for any known application (e.g. Banking application)
Solution: The characteristics of a Banking application are as follows:
 Multi tier functionality to support thousands of concurrent user sessions

 Large scale Integration , typically a banking application integrates with
numerous other applications such as Bill Pay utility and Trading accounts
 Complex Business workflows
 Real Time and Batch processing
 High rate of Transactions per seconds
 Secure Transactions
 Robust Reporting section to keep track of day to day transactions
 Strong Auditing to troubleshoot customer issues
 Massive storage system
 Disaster Management.
File Open - Test case

Steps to reproduce:
1. Launch Application
2. Select "File" menu
File menu pulls down
3. Choose "Open"
"Open" dialog box appears
4. Select a file to open
5. Click OK
Result: File should open
Test case
Test case ID: B 001
Test Description: verify B - bold formatting to the text
Function to be tested: B - bold formatting to the text
Environment: Win 98
Test Execution:
1. Open program
2. Open new document
3. Type any text
4. Select the text to make bold.
5. Click Bold
Expected Result: Applies bold formatting to the text
Actual Result: pass
sample test case for an online purchasing system
1)click the URL link for the online purchasing site.

2)Register if not registered before, Enter user name, login
id and password, Click ‘OK’ button to submit.
3)Enter your login id and password, if you are a.
4)Validate the login id and password, if correct menu page
will be opened.
5) If not correct, display the error message "invalid login
id or password". Re-enter your login id and password.
6)Click the item field and select the item.
7)If available, display the cost and brand, else
display " item is unavailable".

8)click 'YES' to do online purchasing for the item else
click 'NO'.
9)If 'YES' go to the payment type, else display the 'EXIT'
page.
10)click the payment type options and select the mode of
payment.
11)Fill the fields- account holder's name, bank name,
credit/debit card option, card detail, price to be paid,
email id etc.
12) If invalid information is given, show error message "
please re-enter "
13)If black field is present, display message "all the
fields are mandatory".
14)Click "SUBMIT" button.
15)Display the successful submission message "successfully
completed".
16)Press 'EXIT' button.
17)Show the message " successfully logged off".
Ex 5:
AIM: Create a test plan document for any application (e.g. Library Management
System)
Solution:
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.
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.
3 Result
3.1 GUI test
Pass criteria: librarians could use this GUI to interface with the backend library
database without any difficulties
Result: pass
3.2 Database test
Pass criteria: Results of all basic and advanced operations are normal
Result: pass
3.3 Basic function test

3.3.1 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
3.3.2.Update/delete student
Pass criteria:
 The record would be selected using the student ID
Result: pass
 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
3.3.3.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
3.3.4.Update/delete book
Pass criteria:
 The book item can be retrieved using the call number
Result: did not pass. Can not retrieve 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
3.3.5.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
3.3.6.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.
 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
3.3.7.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.
 The due date would automatically be stamped as 5 days from current date.
 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
 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
3.3.8.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
 Books checked out should display correct user details.
Result: pass
3.3.8.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

c. Late fees & Fines summary and total
 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
3.4 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.
4 ENVIRONMENTAL USED
4.1 Hardware: Core2Duo
4.2 Software: Microsoft Windows XP
5 RESOURCES
5.1 Developers of the system are involved in testing process (debugging, unit
testing, even integrity testing)
5.2 Users of the system are involved in testing process (integrity testing)
Ex 6: Study of any testing tool (e.g. Win runner)

Solution:
WinRunner:
 It’s a Functionality Testing Tool.
 It’s a Mercury Interactive’s Testing tool.
 Supports VB, VC++, Java, Power Builder, Delphi, D2K, HTML, Siebel.
 It Records GUI operations in Record mode.
 While Recording, it Automatically generates a Test Script Language(TSL).
 It can do functional Testing of a variety of application software written in
programming languages such as PowerBuilder, VB, C/C++, JAVA and also
on ERP/CRM software packages.
 Run on Windows family Operating Systems.
 XRunner works on Unix and Linux Platforms.
 It Perform Testing in all Windows OS, Browser Environments such as
Internet Explorer.
 It can add checkpoints to compare actual and expected results.
 It provides a facility for synchronization of Test Cases.
 An automated program to apply a test on Application build is called a Test

Script.
 It supports Auto-learning to Recognize Objects and Windows during
recording.
 It support two types of modes of recording.
 Context Sensitive Mode
 Analog Mode
 In the 1st mode, it records Mouse & Keyboard operations w.r.t. to objects
and windows.
 In the 2nd mode, it records Mouse pointer movements on the desktop.
 To change into analog mode follow the steps below.
 Click “Start Recording” twice.
 Go to Create Menu and then click Record Analog
 Press F2 to change from one mode to other.
 Analog mode is used to record digital signatures, Graph drawing and Image
movements.
Testing Process
 Learning (Objects/Windows Recognition)
 Recording (Manual Test into an Automation)
 Edit Script (Checkpoints & Ctrl Stmts)
 Run Script (Execution of Automated Script)
 Analyze Test Results (Defect Tracking for Test Engineers)
Testing an Application
 After installing the software, invoke the WinRunner application
 Start  All Programs  WinRunner WinRunner
 Give Checkmarks for all Add-Ins in the boxes and click Ok.
 Select “New test” to Create a New Test Script (or)
 “Open test” to Open an Existing Test Script (or)
 “Quick Preview” to View the Quick Preview of WinRunner
Recording Testcases
 To test any application first run it and understand its operation.
 Invoke WinRunner,again run the application and record the GUI operations.
 During recording mode,it captures all your actions.
 Once the recording is completed, WinRunner generates a script in TSL.
 Run this Test Script to View the Results generated by WinRunner.
 Test Results will show,If the test has Passed or Failed

 There are Two Modes of recording
1.Context Sensitive Mode (CSM)
2.Analog Mode (AM)
 CSM is used If the locations of GUI Controls or the mouse positions are not
necessary
 If the Mouse Positions and Locations of Controls are needed then use AM
,used to validate bitmaps,testing the signatures etc.
Procedure for Recording a Testcase

 1.File  New [or select “new test "from Welcome Screen]
 2.Open [run]  The application to be tested
 3.Start recording a test case
 Create  Record Context Sensitive [Click “Record” once]
 4.Select the application to be tested by clicking on the application’s title bar
 5.Perform all the actions to be recorded
 6.Once all required actions are recorded, stop the recording
In GUI Map Editor ,WinRunner automatically saves the information from the
application
Procedure to save the information:

 Tools  GUI MapEditor  file  save as  Enter File Name
 Close GUI Map Editor
Procedure for loading the GUI Map File:

 Tools  GUI Map Editor  File  Close all  File  Open  Select File
(x.gui)  list of items displayed during recording phase (double click on
application)
Procedure for Running a Test Case:

 Open a test script to be executed run the test (Run Run from Top or F5)
 WinRunner executes the generated script and displays the results in “Test
Result Window”
Testing Standard Calculator Application Using WinRunner

 Invoke the calculator application from start Programs Accessories
Calculator
 To test complete functionality of the application ,first Generate Test Cases

,which covers all buttons in it
Prepare Test Cases like Some of testcases with correct outputs and some of the
testcases with error messages.
Test cases and Expected outputs for Testing the Calculator Application
Test Case Expected Output

1. 4, 1/x 0.25
2.-6 , sqrt ”Invalid i/p for
function”
3. 4 , C Clears the display
4. 1.2 * 3 3.6
5. 5/2.0 2.5
6. 7 + 8 – 9 6
7. 600 * 2 % 12
8. 2,MS,C,MR 2
9.MC,2,M+,3,M+,C,MR 5
Test case #1: To test Inverse operation (Inverse of 4 using /x button)

Step 1 : Open WinRunner application
Step 2 : Open Calculator application
Step 3 : Create a newdocument [File new] (or) CTRL+N
Step 4 : Start Recording[Click “record” button]
Step 5 : Select Calculator application and start recording the actions(Click 4  1/x
 0.25)
Step 6 : ”Stop” recording [Click “stop” button]
Step 7 : Once the recording is over, WinRunner generates TSL script
Step 8 : Save the file “Inverse” in selected folder
Step 9 : Run from Top (F5)
Step 10: After executing TSL statements ,WinRunner generates test results with
the details
like Passed/failed ,line no ,events ,Details ,Result ,Time, Name of the test
case etc.
Test Case #2 : To test the operation (“Square root of -6”)
Test Case #3 : To clear the display after performing some operations(4 ,C)
Test Case #4 : Multiplication of 2 numbers(1.2*3)
Test Case #5 : Division of 2 numbers (5/2.0)
Test Case #6 : To test the operation(7+8-9)
Test Case #7: To test the operation 2 % of 600 (600*%2)

Test Case #8 : To test MS and MR buttons (2,MS,C,MR)
Test Case #9 : To test M+ and MR buttons (MC,2,M+,3,M+,C,MR)
Test Case #10 : To test MC button

Test Case #11 : To test Backspace.
WinRunner provides 4 types of check points.

 GUI Checkpoint
 Bitmap Checkpoint
 Database Checkpoint
 Text Checkpoint
GUI Checkpoint used to Verify Properties Of objects which has 3 options such as
 For Single Property (Verify a single property of an object)

 For Object/Window (Verify more than 1 property of a Single Object)
 For Multiple Objects (Verify multiple objects with multiple properties)
Navigation/Procedure
 Select Position in the Script

 Go to Create -> GUI Checkpoint
 For Single Property/For Object/Window/For Multiple Objects
 Select Testable Object(s)
 Select Property(s) with Expected Value(s) -> Paste
 It performs Changes in check list files and expected value files due to
sudden changes in Req’s/Test Engineer mistakes.
 Changes in expected values - due to sudden changes in Req’s/Test Engineer
mistakes they can change in expected values through below navigation.
1. Execute Existing Script
2. Open Test Results and Perform Changes in Expected Values
3. Click Ok and Re-Execute the Test to get Correct Result.
 Add new property – we can add new properties to the existing checkpoints
through below navigation.
1. Create -> Edit GUI Checklist -> Select Checklist Filename
2. Click Ok -> Select New Properties to add
3. Click Ok -> Click Ok to Overwrite -> Click Ok after reading
suggestion
4. Change the run Mode “Verify” to “Update”

5. Click Run in Verify mode to get results
6. Analyze the results.
Bitmap Checkpoints
 Its Used to Compare the Images.

Eg: Logo Testing, Digital Signatures/Graphs Comparison.
 It consists of two sub options
 For Object/Window – Compares Expected Image Vs Actual.
 For Screen Area - Compares Expected Image area with Actual.
Procedure for 1st sub option:
1. Select Position in the Script.
2. Create -> Bitmap Checkpoint -> For Object/Window
3. Select Expected Image (Double Click)
Procedure for 2nd sub option:
1. Select Position in the Script.
2. Create -> Bitmap Checkpoint -> For Screen Area
3. Select Required Image Region -> Right Click to Relieve
Database Checkpoints
 Its used to Automate Backend Testing to verify the impact of frontend
operations on the content of backend tables.
 Provides Data Integrity and Data Validation
Procedure:
1. Connect to the Database
2. Execute the Select Statement
3. Capture the result in the Excel Sheet
4. Analyze the result for Data Validation and Data Integrity.
 It Consists of 3 Sub Options.
1. Default Check – Backend Testing depends on DB Content.
2. Custom Check – Depends on Rows/Columns Count & Content.
3. Runtime Record Check – Maps B/W Frontend & Backend Columns.
Text Checkpoints
 Its used to Conduct Calculations and Other Text Based Tests we can use
gettext option in Create Menu.
 It consists of 2 sub options
1. From Object/Window – captures an object value into a variable.
2. From Screen Area – capture the static text from screens.
Procedure for 1st sub option:

 Create -> gettext
 From Object/Window
 Select Object (Double Click).
Procedure for 2nd sub option:
 Create -> gettext
 From Screen Area -> Select Required Value Region
 Right Click to Relieve.
Data Driven Test

 Test Engineers execute tests with multiple test data to validate functionality
is also known as “Retesting”.
 There are 4 types of Data Driven tests.
1. Dynamic Test Data Submission - Execute tests with multiple test data
with tester
2. Through Flat files (.txt) - Conducting retesting based on multiple test
data in flat files
3. From Front End Grids - Conducting retesting based on multiple data
objects like Lists/Menu/ActiveX/Table.
Ex 7: Study of any web testing tool (e.g. Selenium)
Solution: Speed Controller :
In Selenium IDE, Speed controller is used to control the speed of how fast your
test case runs. Set it on fast if you want to run fast test case and set it to slow if you
want to run your test case slow.
Run All Button :
In Selenium IDE, Run All button is used to run the entire test suite. Suppose you
have created 5 test cases for you application and stored all them in one test suite
and if you like to run all they 5 then open your test suite and press this button. it
will run all the 5 test cases one by one.
Run Button :
In Selenium IDE, Run All button is used to run the selected any one test case.
Pause/Resume Button :
In Selenium IDE, pause button is used to pause the running test case and resume
button is used to resume or restart paused test case.
Step Button :
In Selenium IDE, Step button is used to run test commands manually one by one.
Suppose you have paused your test case and now you like to run remaining
commands one by one then you can use step button. Basically step button is used
debug the script in selenium IDE.
Click to Record/ Stop Recording Button :
In Selenium IDE, Record button is used to record the users browser navigation and
creating test script for reusing it and stop record button is used to stop recording.
Command Table :
Command table shows the recorded commands. you can also modify commands or
insert any command in between. there are three elements in each command.
1. Command : Command column describes name of command.

2. Target : Target column describes Target element id or name or Xpath
3. Value : Value column describes Value of an element
Ex 8: Study of any bug tracking tool (e.g. Bugzilla, bugbit)
SOLUTION:
Introduction
Bugzilla is the most popular bug tracking system available today. Bugzilla’s
popularity is due to its highly customizable interface, easy configuration, and
a large community of very active users. With Bugzilla, you can begin
configuring your products, users, and bugs within minutes of starting up the
system. Bugzilla provides you with many features, including:

▪ LDAP integration
▪ SMTP and Sendmail support
▪ Internationalized
▪ User authentication, group security, and SSL support
▪ Voting system
▪ Shortcut flags
▪ Custom fields
▪ Keyword tagging
▪ Saved searches
▪ Voting module
▪ Multiple report types
In this tutorial, you’ll learn how to:

▪ Set parameters and default preferences
▪ Create new users
▪ Create products and components
▪ Modifying default field values
▪ Creating new bugs and modifying existing bugs
Setting Parameters and Default Preferences

When you start using Bugzilla, you’ll need to set a small number of
parameters and preferences. At a minimum, you should change the following
items, to suit your 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 you’re
using. If you’re evaluating a click2try application, select Test. If you’re
using SMTP, set any of the other SMTP options for your environment.
7. In the left side Index list, click Bug Change Policies.

8. Select On for commentoncreate, which will force anyone who enters
a new bug to enter a comment, to describe the bug.
10. Click Default Preferences at the bottom of the page.
11. Select the display order from the drop-down list next to the When
viewing a bug, show comments in this order field.
12. Click Submit Changes.
Creating a New User

Before you begin entering bugs, make sure you add some new users. You
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. You’ll probably want to enable the following
options in the row titled
User is a member of these groups:

o canconfirm
o editbugs
o editcomponents
Adding Products
You’ll add a product in Bugzilla for every product you are developing. To start
with, when you first login to Bugzilla, you’ll find a test product called
TestProduct. You 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.
5. Enter a product name, such as “Widget Design Kit.”
6. Enter a description.
7. Click Add. A message appears telling you that you’ll need to add at least one
component.
To add a component:
1. Click the link add at least one component in the message that appears after you
create a new product.
2. Enter the Component name.
3. Enter a Description.
4. Enter a default assignee. Use one of the users you’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 your product in the message that
reads edit other components of product <product name>.
To modify default field values:
1. At the bottom of the page, in the Edit section, click Field Values.
2. Click the link, in this case OS, for the field you want to edit. The OS field
contains a list of operating
system names. You are going to add browsers to this list. In reality, you 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.
4. In the Value field, enter “IE7.”
5. Click Add.
6. Click Add a value again.
7. In the Value field, enter “Firefox 3.”
8. Click Add.
9. Where it reads Add other values for the op_sys field, click op_sys. This
redisplays the table. You 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 you create a new bug.
To create a new bug:

1. In the top menu, click New.
2. If you’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 you entered.
5. Select one of the options.
6. Enter a summary and a description. You can add any other information you like,
but it is not required by
the system, although you may determine that your bug reporting policy requires
certain information.
7. Click Commit. Bugzilla adds your bug report to the database and displays the
detail page for that bug.
To find a bug:
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.”
3. Select the Status.
4. Select the Product.
5. Enter a word that you think might be in the title of the bug.
6. Click Search. If any bugs meet the criteria you entered, Bugzilla displays them
in a list summary.
7. Click the ID number link to view the full bug report.
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.
Remember it must be in the format of an email address.
3. Click Commit.
Ex: 9 Study of any test management tool (e.g. Test Director)

Solution:
The Test Director testing process includes four phases:
 Specifying Requirements
 Planning Tests
 Running Tests
 Tracking Defects
Starting Test Director
You start TestDirector from your Web browser, using the TestDirector URL.
To start TestDirector:
1 Open the TestDirector Options window.
In your Web browser, type your TestDirector URL:
http://<TestDirector server name>/<virtual directory name>/default.htm
The TestDirector Options window opens.
2 Open TestDirector.
Click the TestDirector link.
The first time you run TestDirector, the application is downloaded to your
computer. Then, each time you open TestDirector, it automatically carries out a
version check. If TestDirector detects a newer version, it downloads the latest
version to your machine.
The TestDirector Login window opens.
3 Select a domain.
In the Domain list, select DEFAULT.
4 Select a project.
In the Project list, select TestDirector_Demo.
5 Log on to the project as a QA tester.

In the User ID box, type one of the following user names: alice_td, cecil_td, or
michael_td. Skip the Password box. A password was not assigned to any of the
above user names. Click the Login button.
TestDirector opens and displays the module in which you were last working. In the
title bar, TestDirector displays the project name and your user name.
To explore the TestDirector window:
1 Explore the TestDirector modules.
➤ Click the Requirements tab. The Requirements module enables you to specify
your testing requirements. This includes defining what you are testing, defining
requirement topics and items, and analyzing the
requirements.
➤ Click the Test Plan tab. The Test Plan module enables you to develop a test
plan based on your testing requirements. This includes defining goals and
strategies, dividing your plan into categories, developing tests, automating tests
where beneficial, and analyzing the plan.
➤ Click the Test Lab tab. The Test Lab module enables you to run tests on your
application and analyze the results.
➤Click the Defects tab. The Defects module enables you to add defects, determine
repair priorities, repair open defects, and analyze the data.
Specifying Testing Requirements
 Defining Requirements
 Viewing Requirements
 Modifying Requirements
 Converting Requirements
Planning Tests
 Developing a Test Plan Tree

 Designing Test Steps
 Copying Test Steps
 Calling Tests with Parameters
 Creating and Viewing Requirements Coverage
 Generating Automated Test Scripts
Running Tests
 Defining Test Sets

 Adding Tests to a Test Set
 Scheduling Test Runs
 Running Tests Manually
 Running Tests Automatically
Adding and Tracking Defects
 Adding New Defects

 Matching Defects
 Updating Defects
 Mailing Defects
 Associating Defects with Tests
 Creating Favorite Views
Ex:10 Study of any open source-testing tool (e.g. Test Link)
Solution:
Test Link: 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 AddTestCaseToTestPlan,
AssignRequirements,CreateTestCase etc. helps create and organize test cases per
test plan. Functions like GetTestCasesForTestPlan, GetLastExecutionResult allows
one to create quality assurance dashboard.
How to use Test Link: Example of TestLink simple work-flow:
1. Initial step would be to create a new Test Project and assign QA testers or
engineers with tasks.
2.Import Software Requirements and for part of these requirements generates

empty Test Cases. Reorganize them into Test Suites.
3.Create a content for empty test cases using test specifications that are being
organized into Test suites.
4.Create “Regression testing” and assigns to applicable test cases.
5.Create a Test Plan, Build and link all Test Cases in Test Suite to this Test Plan.
Assign resources to this test plan.
6.Assume QA got there first Build or Release Candidate from development team,
execute and record the testing with the result.
7.Assume QA get new Build or Release Candidate with fixes for blocking issues,
verify these fixes for blocking issues, execute regression tests.
8.Manager (Test or Engineering) and other project related stakeholders want to see
results and status of testing. Then in such a case, these stakeholders including
managers can create accounts or use default Guest account to view test results for a
particular Build. An overall report gets generated for automated test suites, as a
Guest manager is able to view test results at a higher level in graphical format.
9.Suppose new changes happens to existing functionality, its very easy to modify
existing test plan and add new test cases or enhance/modify existing test cases and
attach them to a particular test plan.
10.Test suites continue to execute as usual by generating various reports.
11.For new project again QA creates a new Test , follows above steps to
implement TestLink for there project.
Ex:11 Study of QTP testing tool
Solution:
Benefits of Automated Testing
If you have ever tested applications or Web sites manually, you are aware of the
drawbacks. Manual testing is time-consuming and tedious, requiring a heavy
investment in human resources. Worst of all, time constraints often make it

impossible to manually test every feature thoroughly before the application is
released. This leaves you wondering whether serious bugs have gone undetected.
Automated testing with QuickTest addresses these problems by dramatically

speeding up the testing process. You can create tests that check all aspects of your
application or Web site, and then run these tests every time your site or application
changes.
As QuickTest runs tests, it simulates a human user by moving the cursor in a Web
page or application window, clicking GUI (graphical user interface) objects, and
entering keyboard input; however, QuickTest does this faster than any human user.
Benefits of Automated Testing

Fast QuickTest runs tests significantly faster than human users.
Reliable Tests perform precisely the same operations each time they are
run, thereby eliminating human error.
Repeatable You can test how the Web site or application reacts after repeated
execution of the same operations.
Programmable You can program sophisticated tests that bring out hidden
information.
Comprehensive You can build a suite of tests that covers every feature in your
Web site or application.
Reusable You can reuse tests on different versions of a Web site or
application, even if the user interface changes.
Testing Process
The QuickTest testing process consists of seven main phases:

1. Preparing to record
Before you record a test, confirm that your application and QuickTest
are set to match the needs of your test.
Make sure your application displays elements on which you want to

record, such as a toolbar or a special window pane, for example, and
that your application options are set as you expect for the purposes of
your test.
2. Recording a session on your application
As you navigate through your application or Web site, QuickTest

graphically displays each step you perform as a row in the Keyword
View. A step is any user action that causes or makes a change in your
application, such as clicking a link or image, or entering data in a
form.
3. Enhancing your test

o Inserting checkpoints into your test lets you search for a
specific value of a page, object, or text string, which helps you
determine whether your application or site is functioning
correctly.
o Broadening the scope of your test, by replacing fixed values
with parameters, lets you check how your application performs
the same operations with multiple sets of data.
o Adding logic and conditional or loop statements enables you to
add sophisticated checks to your test.
4. Debugging your test
You debug a test to ensure that it operates smoothly and without

interruption.
5. Running your test
You run a test to check the behavior of your application or Web site.
While running, QuickTest opens the application, or connects to the
Web site, and performs each step in your test.
6. Analyzing the test results

You examine the test results to pinpoint defects in your application.
7. Reporting defects
If you have Quality Center installed, you can report the defects you
discover to a database. Quality Center is the Mercury test
management Solutionution.
QuickTest Window
Before you begin creating tests, you should familiarize yourself with the main
QuickTest window.
The image below shows a QuickTest window as it would appear after you record a
test, with all toolbars and the Data Table and Active Screen panes displayed:
The QuickTest window contains the following key elements:
 Title bar. Displays the name of the currently open test.

 Menu bar. Displays menus of QuickTest commands.
 Standard toolbar. Contains buttons to assist you in managing your
test.
 View toolbar. Contains buttons to view the various panes that can
assist you in the testing process.
 Tools toolbar. Contains buttons to assist you in setting options,

checking syntax, and working with the Object Spy.
 Automation toolbar. Contains buttons to assist you in the testing

process.
 Insert toolbar. Contains buttons to assist you in inserting steps,

actions, checkpoints, and output values into your test.
 Edit toolbar. Contains buttons to assist you in editing your test steps.
 Debug toolbar. Contains buttons to assist you in debugging tests.
Note: The Debug toolbar is not displayed when you open QuickTest
for the first time. You can display the Debug toolbar by choosing
View > Toolbars > Debug, or by clicking the Debug Viewer button
. This tutorial does not describe how to debug a test. For
additional information, refer to the Mercury QuickTest Professional
User's Guide.
 Action toolbar. Contains buttons and a list of actions, enabling you to

view the details of an individual action or the entire test flow.
Note: The Action toolbar is displayed only in the Keyword View. It is

not displayed when you open QuickTest for the first time. You can
display the Action toolbar by choosing View > Toolbars > Action. If
you insert a reusable or external action in a test, the Action toolbar is
displayed automatically in the Keyword View. For additional

information, refer to the QuickTest Professional User's Guide.
 Test pane. Contains the Keyword View and Expert View tabs.
 Active Screen. Provides a snapshot of your application as it appeared
when you performed a certain step during the recording session.
 Data Table. Assists you in parameterizing your test.
 Debug Viewer pane. Assists you in debugging your test. The Debug
Viewer pane contains the Watch, Variables, and Command tabs.
(The Debug Viewer pane is not displayed when you open QuickTest
for the first time. You can display the Debug Viewer by choosing
View > Debug Viewer, or by clicking the Debug Viewer button
.)
 Information pane. Displays a list of syntax errors found in your test.
 Missing Resources pane. Provides a list of the resources that are
specified in your test but cannot be found, such as unmapped shared
object repositories and parameters that are connected to shared object
repositories. (The Missing Resources pane is not displayed when you
open QuickTest for the first time. You can display the Missing
Resources pane by choosing View > Missing Resources, or by
clicking the Missing Resources button .)
 Status bar. Displays the status of the QuickTest application and other
relevant information.
Some of the panes and toolbar options listed above are described in detail in
subsequent lessons. For information on other panes and toolbar options, refer to the
QuickTest Professional User's Guide.
You can also execute many menu commands using shortcut keys. For additional
information, refer to the "QuickTest at a Glance" chapter in the QuickTest
Professional User's Guide.
Now that you are familiar with the main QuickTest window, take a few minutes to
explore its components.
Text Books
1.
Software Testing techniques, Boris Beizer, Dreamtech, Second Edition
2.
Software Testing Tools by Dr.K.V.K.K. Prasad,Dreamtech press
References
1. The craft of software testing - Brian Marick, Pearson Education.

2. Software Testing, Third Edition, P.C.Jorgensen, Aurbach Publications (Dist.by SPD).
3. Software Testing, N.Chauhan, Oxford University Press.
4. Introduction to Software Testing, P.Ammann and J.Offutt, Cambridge Univ. Press.
5. Effective methods of Software Testing, Perry, John Wiley, Second Edition, 1999.
6. Software Testing Concepts and Tools, P.Nageswara Rao, Dreamtech Press.
7. Software Testing, M.G.Limaye, TMH.
8. Software Testing, Desikan, G.Ramesh, Pearson.
9. Foundations of Software Testing, D.Graham and Others, Cengage Learning.
10. Foundations of Software Testing, A.P.Mathur, Pearson.
Web sites
1) http://www.wikipedia.com
2) www.utest.com
3) www.softwaretestingmentor.com

STV Lab Final Yr

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

STV Lab Final Yr

Загружено:

Авторское право:

Доступные форматы

Software Testing and Case Tools Lab

 Basic & Advanced Models

 Class , Object, Collaboration & Sequence

 Use Cases Advanced Modeling

 Component Diagram & Deployment Diagrams

INTRODUCTION ABOUT LAB

There are 66 systems (Compaq Presario) installed in this Lab. Their

Processor : AMD Athelon ™ 1.67 GHz

Mouse : Optical Mouse

Network Interface card : Present

 Each student has a separate login for database access

 MASM ( Macro Assembler ) is installed in all the systems

 Rational Rose Software is installed in some systems

 Systems are provided for students in the 1:1 ratio.

3. Under stand how to apply UML to Solutionve a number of common problems

UML Syllabus Programs (JNTU)

a. Class diagram for ATM.

b. Use case diagram for ATM.

c. Activity diagram for ATM

d. Sequence diagram ATM

e. Collaboration diagram for ATM

f. Component diagram for ATM

g. Deployment diagram for ATM

h. State Transition diagram for ATM

2. Library Management System

a. Class diagram for LMS

b. Use case diagram for LMS

c. Activity diagram for LMS

d. Sequence diagram LMS

e. Collaboration diagram for LMS

f. Component diagram for LMS

g. Deployment diagram for LMS

h. State Transition diagram for LMS

3. Flight Reservation System

a. Class diagram for FRS

b. Use case diagram for FRS

c. Activity diagram for FRS

d. Sequence diagram FRS

e. Collaboration diagram for FRS

f. Component diagram for FRS

g. Deployment diagram for FRS

h. State Transition diagram for FRS

Description about UML

Through modeling, we achieve four aims.

 Models help us to visualize a system as it is or as we want it to be.

 The choice of what models to create has a profound influence on how

3. Unified Modeling Language (UML)

The UML is a language for

The UML is a Language

 A modeling language is a language whose vocabulary and

The UML is a Language for Visualizing

 Some programmers think of an implementation and then

The UML is a Language for Specifying

 Specifying means building models. It specifies of all the

The UML is a Language for constructing

 The UML is not a visual programming language, but its

The UML is a Language for Documenting

 A Healthy software organization produces all sorts of

 The UML addresses the documentation of a system’s

4. Architectural views of UML

The user model view

- Use Case Diagram - The functionality of a system

The structural model view