Software Testing Lab Manual

Software Practice & Testing
Department of Information Science & Engineering
SOFTWARE PRACICE & TESTING
LAB MANUAL
DEPARTMENT OF INFORMATION SCIENCE & ENGINEERING
R V COLLEGE OF ENGINEERING
I M UMESH
Programmer
Department of ISE
VII SEMESTER
SOFTWARE TESTING CONCEPTS

1. Project and Product
Software is either a project or product. Project has client and Product has no clients. Project is
for the customers and the product is for the market.
2. Software Development Life Cycle
2.1 Requirement Gathering
During requirement gathering, the specific requirements of the software to be built are
gathered and documented.. After gathering requirement, the company will make BRS (Business
Requirement Specification). Once the BRS is finalized, the contract between the company and
the client is signed and the document is called Baseline Business Requirement Specification.
Through BRS document, SRS (Software Requirement Specification) will be prepared. This
document acts as a bridge between customer and the designers chartered to build the product
The SRS document contains,
1. Functional Requirement Specification
2. Non Functional Requirement Specification
FRS is a document which consists of the entire functional flow of the Project.
NFRS consists of the technical architecture of the project i. e., the hardware, softwares and the
server to be used.
2.2 Project Planning
A plan explains how the requirements will be met and by which time. The planning phase is
applicable for both development and testing activities. In this phase, the following will be
decided. At the end of this phase, both project plan and test plan documents are delivered.
2.3 Project Design
The purpose of the design phase is to figure out how to satisfy the requirements enumerated in
the System Requirements Specification. Project Design will be carried out in 2 phases
1. HLD (High Level Design)
2. LLD (Low Level Design)
In HLD phase, data flow diagrams, flow charts and schemas are prepared.
In LLD phase, the pseudo codes, the frameworks and the related database are designed.
2.4 Coding
Developing the software according to the requirement of the client by using some technology is
called coding. This phase produces the software that meets the requirements the design was
meant to satisfy.
2.5 Testing
Testing is the process of ensuring the code developed by the developer is as per the
requirement of the client. By testing the product, an organization identifies and removes as
many defects as possible before releasing it.
2.6 Release and Maintenance
Once the product is tested, it is given to customers to deploy it in their environments. Once all
the functionalities meet the requirement, the software will be in the maintenance phase till
contract with client.
3. Types of Testing
There are three types
White Box Testing

Grey Box Testing
Black box Testing
3.1 White Box Testing (Unit Testing)

Checking the functionality with the knowledge of the internal coding of an application is called
white box testing. Techniques for white box testing are,
Code Coverage
Path Coverage
Condition Coverage
Loop Coverage
Mutation Coverage
Code coverage: Testing the program whether all the written code is executable or not.
Path coverage: Here, the flow charts are written and tested for all independent paths.
Ex:
Main
Module -1
Module-2
Module-3
Module-4
Module-5
Each path will be tested to know how the independent path reaches module-5.
Condition Coverage: All logical conditions should be tested both at their true and false values.
Ex:
If (condition)
{
Statements
}
Else
{
Statements
}
Loop Coverage: Test all the loops for all the cycles.
Ex:
While (loop=10)
{
If (loop==5 & condition A)
{
Break;
}
}
Mutation Coverage: Mutation testing is the process in which the bug is introduced and the
script is checked.
3.2 Grey Box Testing (Integration Testing)
Checking the interface after integrating two or more modules is known as Grey Box Testing.
Interface between the modules can be checked by sending the data from one module to
another module. Then check whether one module is sending the data properly and another
module is receiving the data properly. If the data flow is established between these modules,
then the interface between the modules is correct, otherwise it is a defect.
Approaches to integration testing are,
Incremental Testing
Top down approach

Bottom up approach
Non incremental Testing
Sand witch Approach
Incremental and Non incremental Testing
Big bang approach
Top down approach

Here the data flow between the parent and child-1 will be done first. Then, data flow between
child-1 and child-2 is done. The process continues like this.
Parent
Child-1
Child-2
Child-3
Bottom up approach
Here, the child modules are combined and they are integrated with the parents. Testing starts
from last child
Child-3
Child-2
Child-1
Parent
Big bang Approach

Big bang approach Tests the data flow between the modules randomly. This is done when the
interface is complex.
A
B
E
Sandwich Approach
Doing both incremental and non incremental testing for an application is called sand witch
testing.
Parent
Child-1
Child-2
Child-3
3.3 Black box Testing

Testing the functionalities of an application without the knowledge of internal coding is known
as Black Box Testing. Types of black box testing are,
Functional Testing
Non Functional Testing
3.3.1 Functional Testing

Testing the functionality of an application is known as functional testing. Example: User
interface and front end testing. Types of functional testing are,
GUI Testing
Usability Testing
Functionality Testing
GUI Testing
Testing the look and feel of an application is known as GUI testing. In GUI testing, the tester will
test the features like background colour of an application, logo of an application, font color,
font size, colour of parent and child window etc.,
Usability Testing
Testing user friendliness of an application is known as usability testing.
Functionality Testing
Checking the functionality of the scenario is known as functionality testing.

Form level testing
Form level testing is scenario based testing or it is called as end to end testing. Here, the whole
page is tested i.e., the values for all fields are entered and tested. There are two types of test
cases which can be created positive test cases and negative test case.
Field level testing

Testing only a field in the page is called as field level testing.
3.3.2 Non Functional testing
Load Testing
Applying some load to the server i.e., at the normal condition and checking the response
time is called as load testing.
Stress Testing
Applying abnormal load to the server i.e, applying above the limit (capacity) of the server
and checking the response time of the server is called as stress testing.
Crash Testing
Applying the abnormal load to the threshold point of the server where the server gets
disconnected from the front end due to exceeded limit is called as crash Testing.
Soak Testing
Applying the load to the server for the prolonged period of time is called as soak testing.
Recovery Testing
When a huge load is fired to the server, it gets disconnected or shuts down. The server will
take some time to reboot and restart. Studying the time taken for recovery to the normal
position is known as recovery testing.
Volume Testing
The amount of data given to the machine and checking whether the machine can handle
the load of that data is called as volume testing.
Other important types of Testing
Performance Testing
Applying the load and checking the response time at the given frame of time is called as
performance testing.
Smoke Testing
Testing the major functionality of the application after the deployment of the build is called
as smoke testing. The main objective of doing the smoke testing is to check the stability of
the build or application.
System Testing
System Testing is a form of black box testing. This test validates the accuracy and
completeness in performing the functions as assigned.
End to End Testing

End to end testing is a part of system level testing. Testing the application by scenario is
called end to end testing. This type of testing is also called as scenario testing.
Retesting
Testing the failed test case again and again is called as retesting.
Regression Testing
Testing the software for after change or addition of any part is called as regression testing.
This ensures that change will not have any ill effect on other parts of the software.
Regression Testing is performed in 3 phases.
1. Unit level regression testing
2. Module level regression testing
3. Application level regression testing
Ad hoc Testing
Testing the application randomly without following any process is called as ad hoc testing.
Ad hoc testing is generally done by an experienced person who has the complete
knowledge of the particular domain or project. This type of testing is done when there is a
limited time for release.
Compatibility Testing
Testing the application with different hardware, softwares and operating system is called as
compatibility testing. This type of testing is also called as reliable testing.
Cross browser testing.

Testing the application with different browser is known as cross browser testing.
Exhaustive testing
Testing the complete application with all kind of approach is called as exhaustive testing.
Parallel Testing
Testing the functionality with two different plat forms is called parallel testing.
Security Testing
Testing the authentication and authorization of different levels of users of an application is
known as Security Testing.
4.0 Testing process
Test
Initiation
Test
Plan
Test
Design
Test
Implementation
Test
Execution
Analysis of
Result &
Reporting
4.1 Testing Initiation

The first phase of the testing process is test initiation. In this phase, the tester will be getting
training in the domain, project, testing tools, software configuration management tools etc.,
This phase is also called as knowledge transferring phase.
4.2 Test Plan
The entire testing process is defined here. This document is prepared by the test manager with
senior engineers. It consists of,
1. Introduction to testing and the project
2. Objective
3. Scope of testing
4. Strategies
5. Approach
6. Entry and exit criteria
7. Suspension and resumption criteria
8. Deliverable documents
9. Scheduling
10. Budget
11. Matrix
12. Features to be tested and features not be tested
Introduction to testing and the project
In this section of the test plan, the brief description of the domain, project, the testing team
and their roles and responsibilities will be written. Basically, this case section is prepared by the
project manager and some senior test engineers.
Objective
The goal of the testing team at the end of the project will be mentioned in this section.
Scope of testing
It is an opportunity to get into the application as deeper as possible. Here we will plan the areas
which need to be tested more in the application.
Strategies
Types of testing to be carried out in each and every level of the testing.
Approach
Approach varies in the situation. If the release date gets pre pone, we need to change our
strategy. In many cases, we are forced to go for the adhoc testing.
Entry and Exit Criteria
Here, we will define the entry and exit criteria of each and every level, right from unit level
testing to end of UAT.
Suspension and resumption criteria
Here we will mention when to stop our testing and when to resume (restart) our testing.
Deliverable documents of testing
The deliverable documents are Test Plan document, Test Case document, Bug status report,
RTM document.
Scheduling
Here, we will plan the overall time of testing the application. According to the scheduling, we
will prepare strategy and approach.
Test initiation
Test Plan
Test Case
Execution
Buffer
Budget
The over all expenses to be spent on the project is estimated and planned.
Release
Matrix
There are some matrixes which will be prepared at the starting and at the end of the test
case.
o Requirement Traceability Matrix
o Defect Density Matrix
Requirement Traceability Matrix

The main objective of using RTM document is to find the root cause of the defect. By using
RTM, we will easily come to know the status of the project. There is very less chance of missing
the functionality of the requirement and we can also track the performance of individual
resource. Format of the RTM is as follows.
Requirement id
Description
Priority
Test case IDs
Defect Density Matrix
Defect Density Matrix ==
No. of test case execution

---------------------------------No of Bugs found
Features to be tested and features not be tested
Here, the features to be tested and features not be tested are written, features to be tested
include,
All the functionality of the primary application,
Connectivity to the third party software,
Performance of database,
Look and feel of primary application
Features not be tested include,
Third party software
4.3 Test Design

In this phase, using SRS, test cases are written. Once the test cases are ready, they will be
reviewed by experienced testers.
4.3.1 Use Case
The term USECASE is derived from UML diagram (Unified Modeling Language). UML is a standard way of
representing requirement which will be in pictorial format. It explains the requirement in different
scenarios. The UML gives the clear picture of the entire software process starting from requirement till
implementation. It has nine different diagrams which are used in different stages of software process.
One of them is use case. The template that will be used for designing use cases is shown in Figure
Use Case Name
Use Case ID
Actor
Objective
Precondition
Post condition
Step
User Action
System Response
Relevant Data
Alternate Course
Exceptions
4.3.2 Test case

Test case is a collection of set of input data to validate to validate any software or application.
It is a document to compare the requirement and the execution result. The template that will be
used for designing test cases is shown in Figure
Document Reference No: Functionality 001

Project Name
: Asset Management System
Module Name
: Surplus
Released by
: AMS Batch
Date of release
: 01/04/2007
Remarks
Sl No
Test Case Scenario Description Test Data
ID
Expected
Result
Status
Pass/ Fail
Remarks
Test case writing techniques

Testing can be done at form level or field level.
Form level testing is scenario based testing or it is called as end to end testing. Here, the whole
page is tested i.e., the values for all fields are entered and tested. There are two types of test
cases which can be created positive test cases and negative test case.
Testing only a field in the page is called as field level testing. The techniques used for field level
testing are,
BVA (Boundary Value Analysis)
If the input is in the range of values A-B, then design test cases for A, A+1, A-1 and B, B+1,B-1.
This technique is called as BVA. While writing the code, developers will give conditions like
>100, <50000. So we check the boundary values.
A login page requires user name to be entered. If the requirement is like the username should
accept characters from 4 to 8, BVA is as follows.
X=4, Y=8
X-1, X, X+1
3,4,5
4,5 PASS
Y-1,Y,Y+1
7,8,9
7,8 PASS
3,9 FAIL
If the input is Boolean, then design the test cases for true and false.
ECP (Equivalence Class Partition)

Here classes are created depending on the requirement in the field. i.e., valid class and invalid
class.
Valid Class
Invalid Class
Positive cases
Ex 1:
Valid user name & Password

Click OK
Successful login
Ex 2:
Valid user name & Password

Click Cancel
Should get error message.
Negative test cases

Ex 1:
Empty user name and password

Click OK
Error message should be displayed
Ex 2:
Alphanumeric user name

Click OK
Error message
Ex 3:
Copy & Paste of password should not work
EG (Error Guessing)
In this method, a tester, based on his experience and intuition, guesses probability of certain
types of errors and proceeds to expose them. Testers prepare check list comprising of all
possible errors plus error prone situations. Availability of checklists could make even relatively
less experienced testers intuitive
Characteristics of best test cases.
Best test case is one which has maximum test coverage

If it is given to new test engineer, he should be able to execute the test cases without much
difficulty.
It should catch defects
Minimum steps
4.4 Test Implementation

This phase involves setting up of an environment for test execution. The infrastructure required
to execute tests is made available.
4.5 Test Execution
Executing the test cases after getting the exe file or the build and comparing with the
requirement is known as test execution. If we find any deviation from the requirement, we will
send it to the developer for rectification.
4.6 Analysis of results and reporting
After executing the test cases, we will analyze the result and report to the assigned person. The
developer will pre look to it. If he feels that he has done a mistake, he will rectify and send back
to testing engineer or he will reject the bug.
5.0 Static and Dynamic Testing
Static Testing
It is a verification process
It is about prevention
It us a quality assurance process
Here, the test is conducted without executing
the code and without passing the data into the
application
Examples: Walkthrough
Reviews
Inspection
Dynamic Testing
It is a validation process
It is about cure
It is a quality control process
Here, the test is conducted by passing the data
into application and with executing the code
Examples: Smoke Testing
Functional testing
Integration testing
SOFTWARE PRACTICE & TESTING

Write CRS, SRS, test cases and RTM for Lock / Pen.
CRS for Lock
Functionality of the LOCK

Functionality
Description
Features of lock
It is made of metal, has a facility to insert the

key and ability to turn clock wise and
anticlock wise for a particular key, should not
open even when hit with heavy object
Features of a key
It is made of metal and created to enable

locking and unlocking functions
Actions Performed
States
Inputs
Expected outcome
Key inserted and turned clockwise to lock

Key inserted and turned anticlockwise to
unlock
Locked
Unlocked
Key turned clockwise or anticlockwise
Locking
Unlocking
Sample Requirement Specification for Lock and key System

Sl No
Requirement id
Description
Inserting the key numbered 123 and turning it clockwise
should facilitate locking
Priority
BR-01
BR-02
Inserting the key numbered 123 and turning it

anticlockwise should facilitate unlocking
BR-03
Only key number 123 can be used to lock and unlock
4
5
BR-04
BR-05
M
M
BR-06
No other object can be used to lock

No other object can be used to unlock
The lock and key must be made of metal and must
weigh approximately 150 grams
BR-07
Lock and unlock directions should be changeable for

usability of left handers
L
L
TEST CASES
Document Reference No
Project Name
Module Name
Released By
Date Of Release
Remarks
:
:
:
:
:
:
Functionality 001
Lock
NA
ISE-RVCE
03/09/2013
SL
No:
Test Case ID
Scenario
Discription
TC_LOCK_001
Check the Locking

facility
Insert the key numbered

123
Turn
clock
Insertitthe
keywise
numbered
TC_LOCK_002
TC_LOCK_003 Check for exact key
TC_LOCK_004 Check for exact key
TC_LOCK_005 Check for other objects
5
6
Check the unlocking

facility
Test Data
Expected Result
Should facilitate locking
123
Turn it anticlock wise
125
125
Insert the screw driver
Turn it clock wise
Should facilitate unlocking
TC_LOCK_006 Check for other objects
Insert thin piece of wire

Should not facilitate

antilocking
TC_LOCK_007 Check for the weight
Use weighing machine

Weigh the Lock
Should weigh 150 grams
Should not facilitate locking

Should not facilitate
unlocking
Should not facilitate locking
Actual
Result
Status
Pass/Fail
Remar
ks
Requirement Traceability Matrix

Requirement id
BR-01
Description
Inserting the key numbered 123 and
turning it clockwise should facilitate
locking
Priority
Test case IDs
TC_LOCK_001
BR-02
Inserting the key numbered 123 and

turning it anticlockwise should facilitate
unlocking
TC_LOCK_002
BR-03
Only key number 123 can be used to

lock and unlock
TC_LOCK_003
TC_LOCK_004
BR-04
No other object can be used to lock
TC_LOCK_005
BR-05
No other object can be used to unlock
TC_LOCK_006
BR-06
The lock and key must be made of

metal and must weigh approximately
150 grams
TC_LOCK_007
BR-07
Lock and unlock directions should be

changeable for usability of left handers
Not implemented
Study the functionality of Pen and write CRS, SRS, Test cases and RTM
Derive the functional test cases from the specification of a protocol like SMTP, TCP, IMAP, etc.
Use the test cases to test an actual implementation from the Open Source. Collect the different
metrics from the test execution.
SMTP
On the internet, mail is sent from mail host to mail host using the simple mail transfer protocol
(SMTP). To send and receive mail, you must get it from and send it to a mail host. Every mail
host runs a mail transfer agent (MTA) such as Exim that accepts mails and passes them on.
SMTP functions in two ways. Firstly, it verifies the configuration of the computer from where the
email is being sent and grants permission for the process. Secondly it sends out the message and
follows the successful delivery of the email. If the email can not be delivered, its returned to the
sender.
To test SMTP, we go through 6 steps:
1.
2.
3.
4.
5.
6.
Connect
Handshake
Identify Sender
Identify Recipient
Provide Message Body
End Session
Metrics
Metrics derive information from raw data with a view to help in decision making. Collecting and
analyzing metrics involves effort and several steps. The first step is to decide what measurements
are important and to collect the data accordingly. The effort spent on testing, number of defects,
and number of test cases are some examples of measurements. Measuring and producing metrics
to determine the progress of testing is thus very important.
Following is the test case document to test the functionality of SMTP severs.
Project Name
Module Name
Released By
Date Of Release
Remarks
SL
No
Test Case
ID
:
:
:
:
:
:
Functionality 001
Protocol
SMTP
RVCE-ISE
04/04/2010
Scenario
TC_PTC_SMTP
_001
Test the SMTP

Server setup
TC_PTC_SMTP
_002
SMTP Server
response
TC_PTC_SMTP
_003
Test the SMTP

Mail Address of
Sender
TC_PTC_SMTP
_004
Test the SMTP

Mail Address of
the Receiver
TC_PTC_SMTP
_005
Test the data

flow
TC_PTC_SMTP
_006
Test the data

flow
Description
Open the command
prompt
Type telnet <Server
Name/IP> 25
Hit Enter Key
Open the command
prompt
Type Hello <Server
Name/IP>
Hit Enter Key
Open the command
prompt
Type senders mail ID
Open the command
prompt
Type receiver mail ID
Open the command
prompt
Type Data
Open the command
prompt
Type subject
Hit Enter Key
Test Data
telnet smtpserver 25 or
telnet <ip> 25
Helo smtpserver
mail
from:admin@rvce.com
rcpt to:umesh@rvce.com
Data
This is a test mail

I am testing SMTP Server
Expected
Result
SMTP Server
Message
should appear on
the screen
250 smtpserver
Hello [IP Address]
Message should
appear
Should display
appropriate
message on the
screen
Should display
appropriate
message on the
screen
Should display
appropriate
message on the
screen
Appropriate
message should
appear
Study the functionality of TCP, IMAP and POP3 and write the test cases.
Actual
Result
Status
Pass/Fail
Remarks
Write the test cases to test the most popular features of a popular websites. Automate the test
cases using a tool like Selenium. Execute the test cases from the tool and manually. See the
difference in time taken.
actiTime is an application which includes several modules. Following are some of the
functionalities of actTime.
Enter and view Time-Track for the Current Week, selected month
Enter and Modify Time-Track for Other Users
Staff Output Report
Overtime & Leaves Report
Project & Customer Management
Task Management
User Management
Billing Type Management
Configuring Working and Nonworking days

.
Following is a test case document for testing the login scenario of actiTime application.
Project Name
Module Name
Released By
Date Of Release
Remarks
SL
No
:
:
:
:
:
:
Functionality 001
ActiTime
Login
ISE-RVCE
04/04/2010
Expected
Result
Test Case ID
Scenario
Description
Test Data
TC_AT_LG_001
Successfully
Open the
URL
Open an Explorer
Type URL
Press Button GO
http://127.0.0.1:808
1/login.jsp
TC_AT_LG_002
Successfully
Open the
URL
http://128.0.0.1:808
1/login.jsp
Home page
should not
appear
TC_AT_LG_003
Successful
Login
Open an Explorer
Type URL
Press Button GO
Enter the valid
username
Enter the valid pwd
Press the Login
Button
admin
manager
Should Open
Home Page
TC_AT_LG_004
TC_AT_LG_005
Unsuccessfu
l Login
Enter the invalid

username
Enter the valid pwd
Press the Login
Button
admin1
manager
Unsuccessfu
l Login
Enter the valid

username
Enter the invalid pwd
Press the Login
Button
admin
managar
Home page
should appear
"Username or
Password is
invalid.
Please try
again"
Message
should appear
"Username or
Password is
invalid.
Please try
again"
Message
should appear
Study the functionality of other modules in actiTime application and write the test cases.
Actual
Result
Status
Pass/Fail
Remarks
Selenium
Selenium is a functionality testing tool that supports development of test automation for web
applications. Selenium consists of three major tools each one having specific role viz., Selenium
IDE, Selenium-RC and Selenium-Grid. Selenium-IDE and Selenium-RC are discussed in detail
in this book.
1. Selenium-IDE
Selenium-IDE is an easy-to-use Firefox plug-in. It is an interface for developing and running
individual test cases or group of test cases called test suite. It is the most efficient way to develop
test cases.
To install Selenium-IDE, follow these steps
Download the IDE from the SeleniumHQ downloads page
Open the location Selenium-IDE using Firefox browser (enter the path in URL location)
Select install now.
Restart Firefox
Selenium-IDE listed under the Firefox Tools menu.
Following Screenshots show the installation steps
Open the location Selenium-IDE using Firefox browser, Select Install Now
Restart Firefox
Selenium-IDE listed under the Firefox Tools menu
To start, select Selenium IDE from the Firefox Tools menu. It opens with an empty scriptediting window and a menu for loading, or creating new test cases. The File menu options
include create, open and save test case and test suite files. The options of Edit menu are copy,
paste, delete, undo and select all operations for editing the commands in your test case. The
Options menu is for changing settings. The Help menu is the standard Firefox Help menu; UIElement Documentation item in this menu is related to Selenium-IDE.
The toolbar contains buttons for controlling the execution of your test cases.
Speed Control is used to control the speed of test case running.
Run All is used to run the entire test suite.
Run button is used to run the currently selected test.
Pause/Resume allows stopping and re-starting of a running test case.
Step allows running one command at a time.
Apply Rollup Rules allows grouping of repetitive sequences of Selenium Commands to a single
action.
Record records the users browser actions.
Test Case Pane

The recorded script will be displayed in the test case pane. Test case pane has two tabs, Table
and Source.
Table tab displays the command and their parameters. The Command, Target, and Value entry
fields display the currently selected command along with its parameters. These are entry fields
where you can modify the currently selected command. The first parameter occupies the Target
field and the second parameter occupies the Value field. Commands can be selected by a
populated list after typing a first character.
The Source tab displays the test case in HTML format. It can be changed to a programming
language such as Java or C#, or a scripting language like Python. The Source view enables the
tester to edit the test case.
Bottom pane
This is used for four different functionsLog, Reference, UI-Element, and Rollup
Log tab displays the error messages and other information messages. These messages are used
for test case debugging. The Log pane contents can be cleared by Clear button. Info button
enables selection of different levels of information.
Reference tab displays documentation on the current command. This is very useful as the tester
can ensure that the parameters specified in the target and Value field are correct or not. Corrects
can be done if there is a mismatch.
UI-Element and Rollup
Selenium Commands Selenese

Selenium provides a rich set of commands called Selenese. Using these commands, the tester can
test the existence of UI elements, test for specific content, test for broken links, input fields,
selection list options etc., In addition Selenium commands support testing of window size, mouse
position and many other web-application features.
Selenium command comes in three types; Actions, Accessors and Assertions.
Actions are commands that generally influence the state of the application like type this word,
click this link or logout. The execution of the current test stops if there is any error. Many
Actions can be called with the AndWait suffix, e.g. clickAndWait. This suffix tells Selenium
that the action will cause the browser to make a call to the server, and that Selenium should wait
for a new page to load.
Accessors examine the state of the application and store the results in variables, e.g. storeTitle.
They are also used to automatically generate Assertions.
Assertions verify that the application works as per the expectation. Selenium Assertions can be
used in 3 modes: assert, verify, and waitFor. Suppose an application page should display
List of projects title, verifyTitle command may be used. The test is aborted when an assert
fails. When a verify fails, the test will continue execution, logging the failure. waitFor
commands wait for some condition to become true. They will succeed immediately if the
condition is already true. However, they will fail and halt the test if the condition does not
become true within the current timeout setting.
The following is the list of few frequently used commands.
open
opens a page using a URL.
click/clickAndWait
performs a click operation, and optionally waits for a new page to

load.
verifyTitle/assertTitle
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.
verifyText
verifies expected text and its corresponding HTML tag are present
on the page.
verifyTable
verifies a tables expected contents.
waitForPageToLoad
pauses execution until an expected new page loads. Called

automatically when clickAndWait is used.
waitForElementPresent
pauses execution until an expected UI element, as defined by its

HTML tag, is present on the page.
Building Test Cases

Recording
A test case can be recorded as the user performs actions on website. First, open Mozilla firefox
and Selenium IDE from tools option of the firefox. Then type the base URL and start using the
web application. The record button of Selenium IDE is ON by default. Selenium-IDE inserts
commands based on the user actions. Typically, this will include:
clicking a link - click or clickAndWait commands

entering values - type command
selecting options from a drop-down listbox - select command
clicking checkboxes or radio buttons - click command
Once the recording is over, there is a need to modify some of the commands inserted commands.
For example, click command needs to be changed to clickAndWait to ensure that the test case
pauses until the new page is completely loaded. Otherwise, the test case will continue running
commands before the page has loaded all its UI elements. This will cause unexpected test case
failures.
Saving a Test Case

The save and save as commands in the File menu can be used to save the test cases. The test case
will be saved in HTML format. When required, Open command of File menu can be used to
open saved test case.
Running Test Cases

To run a currently displayed test, Click the Run button.
To run a currently loaded test suite, Click the Run All button
Pause button can be used to stop the test case while it is running. The icon of this button then
changes to indicate the Resume button. To continue click Resume.
Test case can be stopped for debugging purpose using the Toggle Breakpoint. Select Toggle
Breakpoint from the context menu to set a breakpoint at a particular command.
Screen shot shows the recording of a typical case to test the functionality of actiTime demo site.
After recording user actions, one more command verifyTextPresent has been inserted to test the
presence of the text in that particular page.
Screen shot showing the recorded test case in HTML format.
Screen shot showing the successful execution of the test case.
Test Suites
Two or more test cases can be grouped to form test suite. Follow the following steps for creating
automation framework.
1. Record the test cases and store in the folder. Name the folder as Scripts
2. Create a folder with name Results
3. Create an html file with name suite.html. The contents of the file will be like
<html>
<table>
<tr>
<td>Suite</td>
</tr>
<tr>
<td><a target="testFrame" href="Scripts/Task_OpenTaskLink.html">task</a></td>
</tr>
<tr>
<td><a target="testFrame" href="Scripts/User_Creation.html">task</a></td>
</tr>
4. Create a batch file with following contents. Name the file as run.bat
E:
java.exe -jar selenium-server.jar -htmlSuite "*firefox" "http://127.0.0.1:8080/"
"E:/Suite.html" E:/Results/result.html"
Ensure that java is installed, path is set and selenium-server.jar file is present in E drive.
5. Execute the batch file run.bat
6. The test cases will be executed automatically one by one and the results will be available
in the result.html file in Results folder. The contents of result.html looks like.
Screen shot of result.html file
Automate the testing of any two modules of actiTime using Selenium RC.
SELENIUM-RC
Selenium-IDE does not directly support:
1. condition statements
2. iteration
3. logging and reporting of test results
4. error handling, particularly unexpected errors
5. database testing
6. test case grouping
7. re-execution of failed tests
8. test case dependency
9. screenshot capture of test failures
Selenium-RC allows the test automation developer to use a programming language for maximum
flexibility and extensibility in developing test logic. Selenium-RC is the solution for tests that
need more than simple browser actions and linear execution. Selenium-RC uses the full power of
programming languages to create more complex tests like reading and writing files, querying a
database, emailing test results.
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 projects automated build environment.
Although these tasks are not supported by Selenium directly, all of them can be achieved by
using programming techniques with a language-specific Selenium-RC client library. In the
Adding Some Spice to Your Tests section, youll find examples that demonstrate the advantages
of using a programming language for your tests.
Selenium-RC Components
The Selenium Server
Launches and kills browsers, interprets and runs the Selenese commands passed from the test
program.
Selenium Server receives Selenium commands from your test program, interprets them, and
reports back to your program the results of running those tests.
The Client libraries

Provide the interface between each programming language and the Selenium-RC Server.
Provide the programming support that allows you to run Selenium commands from a
program of your own design. The client library also receives the result of that command and
passes it back to your program.
How it works?
1. The client/driver establishes a connection with the selenium-RC server.
2. Selenium-RC server launches a browser (or reuses an old one) with an URL that injects
SeleniumCores JavaScript into the browser-loaded web page.
3. The client-driver passes a Selenese command to the server.
4. The Server interprets the command and then triggers the corresponding JavaScript
execution to execute that command within the browser.
5. Selenium-Core instructs the browser to act on that first instruction, typically opening a
page of the AUT.
6. The browser receives the open request and asks for the websites content to the SeleniumRC server (set as the HTTP proxy for the browser to use).
7. Selenium-RC server communicates with the Web server asking for the page and once it
receives it, it sends the page to the browser masking the origin to look like the page comes
from the same server as Selenium-Core (this allows Selenium-Core to comply with the Same
Origin Policy).
8. The browser receives the web page and renders it in the frame/window reserved for it.
Reporting Results
Selenium-RC does not have its own mechanism for reporting results. Rather, it allows you to
build your reporting customized to your needs using features of your chosen programming
language.
Installation
1. Install the Selenium-RC Server.
The Selenium-RC server is simply a Java jar file (selenium-server.jar), which doesnt require any
special installation. Just downloading the zip file and extracting the server in the desired
directory is sufficient.
2. Set up a programming project using a language specific client driver.
After downloading the Selenium-RC zip file from the downloads page, youll notice it has
several subfolders. These folders have all the components you need for using Selenium-RC with
the programming language of your choice.
3. Running Selenium Server
Before starting any tests you must start the server. Go to the directory where Selenium-RCs
server is located and run the following from a command-line console.
java -jar selenium-server.jar
This can be simplified by creating a batch or shell executable file (.bat on Windows and .sh on
Linux) containing the command above. Then make a shortcut to that executable on your desktop
and simply double-click the icon to start the server. For the server to run youll need Java
installed and the PATH environment variable correctly configured to run it from the console.
4. Configuring Selenium RC using eclipse
Eclipse is a multi-language software development platform comprising an IDE and a plug-in

system to extend it. It is written primarily in Java and is used to develop applications in this
language and, by means of the various plug-ins, in other languages as well as C/C++, Cobol,
Python, Perl, PHP and more.
Following lines describes configuration of Selenium-RC with Eclipse.
Launch Eclipse.
Select File > New > Other.
Java > Java Project > Next

Provide Name to your project, Select JDK in Use a project Specific JRE option
Click Finish > Click on Yes in Open Associated Perspective pop up window.
This would create Project RVCE in Package Explorer/Navigator pane.
Right click on src folder and click on New > Folder

Name this folder as UserCheckFunctions and click on Finish button.
This should get UserCheckFunctions package insider src folder.
Configuring build path
Right click on lib folder > Build Path > Configure build Path
Under Library tab click on Add External Jars to navigate to directory where jar files are saved.
Select the jar files which are to be added and click on Open button.
After having added jar files click on OK button.
Added libraries would appear in Package Explorer as following:
Screenshots of adding selenium-java-client-driver.jar and selenium-server.jar files to the project

as references.
TestNG
Eclipse has direct support for these via TestNG plug-in. TestNG is a testing framework designed
to simply a broad range of testing needs, from unit testing to integration testing.
Steps to follow
Write the business logic of your test and insert TestNG annotations in your code.
A TestNG test can be configured by @BeforeClass and @AfterClass annotations which
allows to perform some Java logic before and after a certain point, these points being either of
the items listed above.
Annotations
Here is a quick overview of the annotations available in TestNG along with their attributes.
@ BeforeTest: The annotated method will be run before any test method belonging to the
classes inside the <test> tag is run.
@ AfterTest: The annotated method will be run after all the test methods belonging to the
classes inside the <test> tag have run.
An Example
import com.thoughtworks.selenium.*;
import org.testng.annotations.*;
public class SimpleTest {
private Selenium selenium;
@BeforeClass
public void setup()
{
selenium=new DefaultSelenium("localhost",4444,"*firefox","http://umesh-pc/login.do");
selenium.start();
}
@Test
public void login(){
selenium.open("/login.do");
selenium.type("username", "admin");
selenium.type("pwd", "manager");
selenium.click("loginButton");
selenium.waitForPageToLoad("30000");
selenium.click("logoutBtn");
selenium.waitForPageToLoad("30000");
}
@AfterClass
public void tearDown()
{
selenium.stop();
}
}
Running TestNG
TestNG can be invoked using Eclipse
Automate the testing of any two modules of actiTime using Selenium-Automation-Framework
SAF Architecture
SAF uses a hybrid test automation approach. It has been built on Selenium RC. Components of
SAF are:
Test Suite Configuration
Test Scripts / Test Suite
Execution Engine
Reporting Engine
Recovery & Exception Handling Engine
SAF Layers
Core of SAF framework is the Execution Engine. The engine consists of 6 main components:
1. Build.xml: starts the Selenium server and kick start script execution.
2. SAF : is invoked by Build.xml which in turn calls XlateExcelToHtml and XlateHtmlToJava
3. XlateExcelToHtml: converts the test cases in the excel sheet to HTML scripts
4. XlateHtmlToJava: converts the HTML scripts to Java.
5. LogUtil.java (Error handler): When there is an exception it is recorded in Error. log
6. log4jConfig.properties : This file has the Config and display details for Error.log
SAF takes the input from user in form of Config, Test Cases and Test Suite. The execution
engine internally invokes Build.xml to start the Selenium server and kick-start script execution.
Error handler is invoked in cases of exception and the log file gets generated. At the end of the
execution fairly standard and simple reports in html format are provided to the user
Steps to achieve full potential of SAF

Flow explains the potential of SAF in simple steps:
1. Environment setup
2. Test Suite Configuration settings
3. Develop Test cases
4. Update MasterTestSuite.txt file
5. Execute the test, analyze the reports
Step One:- Environment setup

Prerequisite:
1. JDK 1.6 or later
2. ANT 1.7 or later
3. MS Excel
4. Any one of the following browser to run test scripts
a. IE (versions 6/7/8/9)
b. FF (versions 3, 4, 5, 6, 7,8,9)
c. Safari (version <=4.0)
d. GoogleChrome (version <=12.0 for regular SAF, >12.0 for SAF with webdriver)
1. Unzip SAF.zip file and install SAF.exe file into your local disk.
2. Copy \\jars\tools.jar file to C:\Program Files\Java\jre1.6*\lib\tools.jar
3. Run \\jars\ISAF.bat file to set environment variables / CLASSPATH as appropriate. PS:
User needs to set JRE & ANT paths in the environment variables manually if the settings
should remain even after restarting user machine. To confirm settings are reflected
appropriately, go to the command prompt and give java version and ant version.
4. How to Set CLASSPATH and PATH for Java and Ant?
Steps:
1. Right click on "My Computer"
2. Select "Properties" >> Opens "System Properties Dialog"
3. Select "Advanced" Tab
4.
Click on "Environment Variable" >> Opens "Environment Variable Dialog"

5.
Below System Variable section , Click on New button

set JAVA_HOME=D:\Program Files\Java\jdk1.5.0_06
set ANT_HOME=D:\Ant\apache-ant-1.6.2
Edit Path and append value at end: PATH=%PATH%;%ANT_HOME%\bin
set CLASSPATH=%CLASSPATH%;%ANT_HOME%\lib;%JAVA_HOME%\lib
5. An extracted SAF folder should have :

Folder
\SAF5.*\
Content
build.xml
\config
\jars
README.txt
\Testcases
RunTestSuite.bat
\SAF5.*\jars\
ant.jar log4j-1.3alpha-7.jar
ant-contrib-1.0b3.jar
selenium-java-client-driver.jar
selenium-server.jar
suite.jar
testng-5.9-jdk15.jar
tools.jar
\SAF5.*\Testcases\
SAF_Template5.3.xls
SAF_TestDataTemplate5.3.xls
Sample Test cases
\SAF5.*\config\
log4jConfig.properties
MasterTestSuite.properties
MasterTestSuite.txt
suite.xml
encryp_ED.txt
encryp_hrs.txt
encryp_SD.txt
Step Two:- Test Suite Configuration settings
1. Mode of Test Case Execution: Remote or Local host

Remote: You can run the scripts on a remote machine given the URL of the machine
provided the Selenium RC server is running on the remote machine. To start the
server from the command prompt change directory to the \\jars> and given
\\jars> java -jar selenium-server.jar -multiwindow
Local host : run the scripts on the Local machine
2. Application URL: The Base URL of the web application under test.
3. Browser Type: *iehta , *iexplore,*chrome, *firefox
*iehta: Invokes the web application on a IE browser .This option can be used when
the application uses HTTPS protocol. *iehta is special mode for running the browser
that basically has *no* security turned on... JavaScript in the Selenium engine can do
*anything* (like visit multiple sites and do file uploads) in this mode that is otherwise
prevented in
"normal" *firefox and *explorer modes
*iexplore: Invokes the web application on an IE browser. This option can be used
when the application uses HTTP protocol.
*chrome: invokes the web application on a Fire fox browser. chrome is a special
mode for running the browser that basically has *no* security turned on... JavaScript
in the Selenium engine can do *anything* (like visit multiple sites and do file uploads)
in this mode that is otherwise prevented in "normal" *firefox and *explorer modes
*firefox: invokes the web application on a Fire fox browser
4.
Execution Speed: fast , moderate, slow

Fast: is the default mode. It executes the scripts in a fast mode
Moderate: executes the scripts in a moderate mode. Add a delay of 1 sec between
each action while executing the scripts
Slow: executes the scripts in a slow mode. Add a delay of 2 sec between each
action while executing the scripts
5. Results/Screen shot path : specify the path where the screenshot have to be stored
6. Please select Mode of Test Suite Execution: (Sequential OR Concurrent execution) default is Sequential
Sequential: default is Sequential, executes all the scripts in a sequential manner
Concurrent: executes the scripts in different browsers parallel, currently it executes
on 3 browsers in parallel.
7. Please select from the options:
On the fly Execution: is the default selection, Executes the scripts from the excel
file. This option is available only for Sequential Test Case Execution Mode
Generate Script: Converts the entire excel scripts to Java file
Generate & Execute script: Converts the excel scripts to java file and then
executes the java file
Generate script for Selected test: Generates java file for those test between
Generate Java Code from and Generate Java Code to block
Generate & Execute script for selected tests: Generates and Executes.java file
for those test between Generate Java Code from and Generate Java Code to
block
Execute user updated java file:
Using this option, users with little Java
programming skills can now modify & execute generated Java code in any editor and
execute from with in the SAF command prompt, This option will execute the newly
modified code irrespective of the option specified in Do you want to execute

modified Test case field.
8. Generate Java Code from TestCase: Used for selective script generation and execution,
specify the name of the test case from where the java files have to be generated.
9. Generate Java Code till TestCase: Used for selective script generation and execution, the
name of the Test case to where the java files have to be generated.
10. Name of the Generated Script: The name you want to give for the java script. If the java
file with the same name is already existing, then it will be overridden with the recently
generated file
11. Path of the External Test Data File: Specify the path of the external excel file, in case if the
user want to perform DDT(Data Driven Testing) from an external file
12. Do you want to execute modified Testcase: User should select No if he wants to execute
previously generated .class / test script file and the default selection is Yes.
For details on executing the generated code, please refer to section 4 How to execute Generated Java code
Step Three :- Develop Test cases
1. Open Test Cases sheet

2. Test Case sheet will have the following headers under the sheet name called Keyword
TCID: Write the test case id under. For Ex: - Bugzilla_App_Start .
Actions: Select the action from dropdown present in the Action column.
Object: Use IE Developer to identify the element IDs and fill the Object columns.
Value: Value to be entered for the object (Eg: Login , Password)
Flag: Ex and Nex, Ex: tells SAF to execute the current command line; Nex: tells SAF not
to execute this line.
PS: This column shouldnt be left blank for existing rows, please specify Nex to exclude the
test case from execution.
UDE: Use this column, in case of test case failure to have a User Defined
Exception/Error/Debug messages in the error.log file. User should type UDE: and then
specify the exception message.
Perform Security Testing of the actiTIME website.

Testing the authentication of and authorization of the system is called security testing. There are
many types of testing done to ensure the application is secured.
Testing by pasting internal URL directly into the browser address bar without logging in and the
internal page should not be displayed.
Password cannot be copied.
Testing the application by enabling and disabling cookies (Temporarily and permanent)
Web directories should not be accessible unless given the download option.
The primary reason for testing the security of a web is to identify potential vulnerabilities and
subsequently repair them.
Following are some of the test case scenarios which can be executed on web site.
Sl No
Scenario
Description / Steps
Check password complexity

during registration
1. Check password confirms and required length with combination of lower and upper case
and special keywords
2. Check the password does not belong to dictionary
Check account lockout happens

after few unsuccessful attempts
during login
1. Check the error message displayed does not tell which part of authentication credentials
are incorrect
2. Check the status failure or success after few seconds once the user enter the credentials
Check change password screen
1. Check that change password screen have old password field mandatory
2. Check to ensure that password field does not have Auto complete feature "ON"
3. Check the new password is not displayed in screen but is sent to user mail id
4. Check to see that account gets locked if user tried to enter old password incorrect for
more than 3 attempts
Insufficient session expiration
Check that the application logs off or session is expired after some time
(All application pages)
Session Hijacking
1. Check whether session ids are predictable

2. Check multiple session same user is not allowed
3. Check important data is transferred using HTTPs protocol
Perform security testing of actiTIME website using few scenarios mentioned above.
=========================================================

Software Testing Lab Manual

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Software Testing Lab Manual

Enviado por

Direitos autorais:

Formatos disponíveis

Software Practice & Testing

Department of Information Science & Engineering

SOFTWARE PRACICE & TESTING

Software Practice & Testing

Department of Information Science & Engineering

SOFTWARE TESTING CONCEPTS

Software Practice & Testing

Department of Information Science & Engineering

White Box Testing

3.1 White Box Testing (Unit Testing)

Software Practice & Testing

Department of Information Science & Engineering

Software Practice & Testing

Department of Information Science & Engineering

Top down approach

Non incremental Testing

Sand witch Approach

Incremental and Non incremental Testing

Big bang approach

Top down approach

Software Practice & Testing

Department of Information Science & Engineering

Big bang Approach

Software Practice & Testing

Department of Information Science & Engineering

3.3 Black box Testing

3.3.1 Functional Testing

Checking the functionality of the scenario is known as functionality testing.

Software Practice & Testing

Department of Information Science & Engineering

Field level testing

3.3.2 Non Functional testing

Software Practice & Testing

Department of Information Science & Engineering

Other important types of Testing

End to End Testing

Software Practice & Testing

Department of Information Science & Engineering

Cross browser testing.

Software Practice & Testing

Department of Information Science & Engineering

4.0 Testing process

Software Practice & Testing

Department of Information Science & Engineering

4.1 Testing Initiation

Introduction to testing and the project

Software Practice & Testing

Department of Information Science & Engineering

Entry and Exit Criteria

Suspension and resumption criteria

Deliverable documents of testing

Software Practice & Testing

Department of Information Science & Engineering

Requirement Traceability Matrix

Test case IDs

Defect Density Matrix

Defect Density Matrix ==

No. of test case execution

Features to be tested and features not be tested

Software Practice & Testing

Department of Information Science & Engineering

4.3 Test Design

4.3.2 Test case