STANNS COLLEGE OF ENGINEERING &TECHNOLOGY

SOFTWARE TESTING METHODOLOGIES

Unit-5

Syllabus:
Automation and Testing Tools: need for automation, categorization of testing tools, selection of
testing tools, Cost incurred, Guidelines for automated testing, overview of some commercial testing
tools such as Win Runner,Load Runner,Jmeter and Junit.Test Automation using Selenium Tool.
Testing Object Oriented Software: basics, Object oriented testing
Testing Web based Systems: Challenges in testing for web based software, quality aspects, web
engineering, testing of web based systems, Testing mobile systems.

Automation and Testing Tools

• Automation Testing is a software testing technique that performs using special automated
testing software tools to execute a test case suite.

5.1 Need for

Automation:
If an organization needs to choose a testing tool, the following benefits of an automation must be
considered:

--Reduction of testing Effort: execution of test suits through software tools greatly reduces the
amount of time required

--Reduces the testers’ involvement in executing tests: testers can do some other work
increasing the parallelism in testing efforts
--Facilitates Regression Testing: If we automate then testing effort as well as the time taken will
reduce as compared to manual testing.

--Avoids Human mistakes: Manually executing may incorporate errors

--Reduces overall cost of the software: testing tools usage leads to reduction of time,cost to grater
level
--Simulated testing: Automated tools can create millions of concurrent virtual users/data
--Internal Testing : memory leakage or coverage testing can be done quickly and
accurately
--Test case Design: tools can be used to design test cases

5.2 Categorization of Testing Tools:

Static Testing Tools
Dynamic Testing Tools
Testing Activity Tools

5.2.1STATIC AND
DYNAMICTESTING TOOLS

1.Static Testing Tools:

For Static Testing, there are static program analysers which scan the source program and
detect all possible faults and anomalies. These static tools parse the program text, recognize the
various sentences, and detects the following:
--Statements are well formed.
--Inferences about the control flow of the program.
-- Compute the set of all possible values for program data.

Static tools perform the following types of static analysis:

--Control Flow Analysis: detects loops with multiple exits and entry points and unreachable
code
--Data use Analysis: It detects all types of data faults
--Interface Analysis: It detects all interface faults
--Path Analysis: identifies all possible paths through the program

2.Dynamic Testing Tools:

Automated test tools enable the test team to capture the state of events during the execution
of a program by preserving a snapshot of the conditions. These tools are sometimes called Program
Monitors. These monitors perform the following functions:
--List the number of times a component is called of line of code is executed. This information is
used by testers about the statement or path coverage of their test cases.
--Report on whether a decision point has branched in all directions, thereby providing
information about branch coverage.
--Report summary statistics providing a high level view of the percentage of statements, paths,
and branches that have been covered by the collective set of test cases run. This information is
important when test objectives are stated in terms of coverage.
 5.2.2 Testing Activity Tools: These tools are based on the testing activities or tasks in a particular
phase of the SDLC.
Testing activities can be categorized as:
--1.Tools for Review and Inspections
--2.Tools for Test Planning
--3.Tools for Test Design and Development
--4.Test Execution and Evaluation Tools

1.Tools for Review and Inspections: Since these tools are for static analysis on many items, some
tools are designed to work with specifications but there are far too many tools available that work
exclusively with code. In this category, the following types of tools are required:

a)Complexity Analysis Tools: It is important for testers that complexity is analysed so that testing
time and resources can be estimated.
b)Code Comprehension: These tools help in understanding dependencies, tracing, program logic,
viewing graphical representations of the program.

2.Tools for Test Planning: The types of tools required for test planning are:
-- Templates for test plan documentation.
-- Test schedule and staffing estimates.
-- Complexity analyser.

3.Tools for Test Design and Development:

Test data generator: It automates the generation of test data based on a user defined format.
Test case generator: It automates the procedure of generating the test cases. But it works with
a requirement management tool which is meant to capture requirements information.

4.Test Execution and Evaluation Tools:

i)Capture/Playback Tools: These tools record events (keystrokes, mouse activity, display output)
at the time of running the system and place the information into a script.

ii)Coverage Analysis Tools: These tools automate the process of thoroughly testing the software
and provide a quantitative measure of the coverage of the system being tested.

iii)Memory Testing Tools: These tools verify that an application is properly using its
memory resources.

iv)Test management Tools: Some test management tools such as Rationals TestStudio are
integrated with requirement and configuration management and defect tracking tools, in order to
simplify the entire testing life cycle.

v)Network-testing Tools: These tools monitor, measure, test and diagnose performance across an
entire network.

vi)Performance testing Tools: These tools helps in measuring the response time and load capabilities
ofsystem
 .

5.3 Selection of Testing Tools:

• It may depend on several factors.

• What are the needs of the organization.
• what is the project environment;
what is the current testing methodology

Some guidelines to be followed by selecting a testing tool are given below.

--Match the tool to its appropriate use
--Select the tool to its appropriate SDLC phase
--Select the tool to the skill of the tester
--Select a tool which is affordable
--Determine how many tools are required for testing the system
--Select the tool after having the schedule of testing

--Match the tool to its appropriate use: the tester needs to be familiar with both the tool and its
uses in order to make a proper selection
--Select the tool to its appropriate SDLC phase: it is necessary to choose the tool according to the
SDLC phase
--Select the tool to the skill of the tester: The individual performing the test must select a tool that
conforms to his skill level

--Select a tool which is affordable: choose the tool which is within the budget of the project
--Determine how many tools are required for testing the system: It may be possible that many
test tools are required for the entire project
--Select the tool after having the schedule of testing: First, get an idea of the entire schedule of
testing activities and then decide about tool

5.4 Cost incurred in Testing Tools:

• Automation is not free.
• employing the testing tools incur a high cost.

Following are some facts pertaining to the cost incurred in testing tools

Automated Script Development: Automated test tools do not create test scripts. Therefore,
a significant time is needed to program the tests.

Training is required: Testers require training regarding the tool, otherwise the tools may end up on
the shelf or implemented inefficiently.

Configuration Management: It is necessary to track large number of files and test related artifacts.

Learning Curve for the Tools: Tests scripts generated by the tool during recording must be
modified manually, requiring tool-scripting knowledge in order to make the script robust, reusable
and maintainable.

Testing Tools can be Intrusive: It may be necessary that for automation some tools require that a
special code is inserted in the system to work correctly and to be integrated with the testing tools.
These types of tools are called as intrusive tools.

Multiple Tools are required: It may be possible that your requirement is not satisfied with just one
tool for automation.

5.5 Guidelines for Automated Testing:

Consider building a tool instead of buying one if possible: If the requirement is small and
sufficient resources allow then go for building the tool instead of buying.

Test the tool on an application prototype: While purchasing the tool it is important to verify that
it works properly with the system being developed.

Not all the tests should be automated: Automated testing is an enhancement of manual testing,
but it cannot be expected that all test on a project can be automated.

Select the tools according to Organization needs: Focus on the needs of the Organization and
know the resources (budget, schedule) before choosing the automation tool.

Use proven test-script development techniques: Automation can be effective if proven techniques
are used to produce efficient, maintainable and reusable test-script.

Automate the regression tests whenever feasible: Regression testing consumes a lot of time. If
this testing, the testing time can be reduced to a greater extent.

5.6 Overview of Some Commercial Testing Tools:

Mercury Interactive’s WinRunner:

WinRunner, Mercury Interactive’s enterprise functional testing tool. It is used to quickly
create and run sophisticated automated tests on your application.
Winrunner helps you automate the testing process, from test development to execution.
You create adaptable and reusable test scripts that challenge the functionality of your application.
Prior to a software release, you can run these tests in a single overnight run- enabling you to detect
and ensure superior software quality.
Main Features of Win Runner are:
--Developed by Mercury Interactive
--Functionality testing tool
--Supports C/s and web technologies such as (VB, VC++, D2K, Java, HTML, Power Builder,
Delphe, Cibell (ERP))
--To Support .net, xml, SAP, Peoplesoft, Oracle applications, Multimedia we can use QTP.
--Winrunner run on Windows only.
--Tool developed in C on VC++ environment.

Segue Software’s SilkTest:

Robust and portable test automation for web, native, and enterprise software applications.
Silk Test's portability enables users to test applications more effectively with lower complexity and
cost in comparison to other functional testing tools on the market.
Silk Test's role based testing enables business stakeholders, QA engineers, and developers to
contribute to the whole automation testing process, which drives collaboration and increases the
effectiveness of software testing.
IBM rational SQA Robot:
Rational Robot is an automated functional, regression testing tool for automating Windows, Java, IE
and ERP applications under windows platform. Rational Robot provides test cases for common
objects such as menus, lists, bitmaps and specialized test cases for objects specific to the
development environment.

Mercury Interactive’s LoadRunner:

Mercury LoadRunner is an automated performance and load testing tool from Hewlett-Packard
(HP). An industry standard, Mercury LoadRunner is used to predict an application's behavior and
performance prior to live release. It is an enterprise-class solution for analyzing system behavior
and performance.
 Apache’s Jmeter
The Apache Jmeter application is open source software, a 100% pure Java application designed to
load test functional behavior and measure performance. It was originally designed for testing Web
Applications but has since expanded to other test functions.

JUnit
JUnit is a unit testing framework for Java programming language. It plays a crucial role test-driven
development, and is a family of unit testing frameworks collectively known as xUnit.

JUnit promotes the idea of "first testing then coding", which emphasizes on setting up the test data
for a piece of code that can be tested first and then implemented.
Features of JUnit
 JUnit is an open source framework, which is used for writing and running tests.
 Provides annotations to identify test methods.
 Provides assertions for testing expected results.
 Provides test runners for running tests.
 JUnit tests allow you to write codes faster, which increases quality.
 JUnit is elegantly simple. It is less complex and takes less time.

Mercury Interactive’s TestDirector

TestDirector is a test management tool which includes:
It manages the test process with four phases: specifying
requirements, planning tests, running tests, and tracking defects
--Requirements Management – Helps in the recording and linking of software requirements in
TestDirector to ensure traceability of requirements through to test cases and to defects.
--Test Plan - Helps in the documentation of test plans (IEEE 829 test procedures and test cases)
using TestDirector. In the case of manual tests, Gillogley Services is experienced in the realisation
of test strategy, test planning as well as test design through the creation of TestDirector test cases.
--Test Lab – Helps in managing the execution of tests including the reporting of progress of testing
using Mercury Test Lab.

Test Automation using Selenium Tool

Selenium is a free (open-source) automated testing framework used to validate web applications
across different browsers and platforms. You can use multiple programming languages like Java, C#,
Python etc to create Selenium Test Scripts. Testing done using the Selenium testing tool is usually
referred to as Selenium Testing.
 Selenium can be used to automate functional tests and can be integrated with automation test tools
such as Maven, Jenkins, & Docker to achieve continuous testing.
It can also be integrated with tools such as TestNG, & JUnit for managing test cases and generating
reports

Features of Selenium

Selenium Features
o Selenium is an open source and portable Web testing Framework.
o Selenium IDE provides a playback and record feature for authoring tests without the need to
learn a test scripting language.
o It can be considered as the leading cloud-based testing platform which helps testers to record
their actions and export them as a reusable script with a simple-to-understand and easy-to-use
interface.
o Selenium supports various operating systems, browsers and programming languages.
o Languages supported by Selenium include C#, Java, Perl, PHP, Python and Ruby
o Browsers supported by Selenium include Internet Explorer, Mozilla Firefox, Google Chrome
and Safari
o It also supports parallel test execution which reduces time and increases the efficiency of tests.
o Selenium can be integrated with frameworks like Ant and Maven for source code compilation
o Selenium can also be integrated with testing frameworks like TestNG for application testing
and generating reports.
o Selenium requires fewer resources as compared to other automation test tools.
o WebDriver API has been indulged in selenium which is one of the most important
modifications done to selenium.
o Selenium web driver does not require server installation, test scripts interact directly with the
browser.
o Selenium commands are categorized in terms of different classes which make it easier to
understand and implement.
 o Selenium Remote Control (RC) in conjunction with WebDriver API is known as Selenium 2.0.
This version was built to support the vibrant web pages and Ajax.

Selenium Testing Tools

Selenium is not just a single tool but a suite of software, each with a different approach to support
automation testing. It comprises of four major components which include:

1. Selenium Integrated Development Environment (IDE)

2. Selenium Remote Control (Now Deprecated)
3. WebDriver
4. Selenium Grid

Selenium IDE

Selenium IDE is a free plugin on the browser that helps you record, edit, debug, and replay functional
tests.

 Selenium RC: allows multiple tests to be performed continuously and works with a Selenium RC
server.

Selenium WebDriver

Selenium WebDriver is a browser-based driver that helps in accessing and launching different
browsers.

Test engineers and developers will find many options to leverage Selenium WebDriver technology. A
lot of frameworks have been derived from Selenium and extended its capabilities. These include
Protractor, WebDriverIO, CodeceptJS, etc.

Selenium Grid

Selenium Grid has a hub-and-node architecture that helps you do parallel tests across different
browsers.

5.7 Testing Web based Systems

Challenges in testing for web based software, quality aspects, web engineering, testing of web
based systems, Testing mobile systems.

• WEB-BASED SYSTEM
• The web-based software system consists of a set of web pages and components
• that interact to form a system which executes using web server(s), network, HTTP, and a
browser, and in which user input affects the state of the system
 5.7.1 Challenges in testing for web based software:
Some of the challenges and quality issues for web-based system are
Diversity and Complexity: Web applications interact with many components that run on diverse
hardware and Software platforms.

Dynamic Environment: The dynamic nature of web software creates challenges for the analysis,
testing, and maintenance for these systems.

Very short development time: Clients of web based systems impose very short development time,
compared to other software systems.

Continuous evolution: Demand for more functionality and capacity after the system has been
designed and deployed to meet the extended scope and demands i.e Scalability issues.

Compatibility & Interoperability: Web applications often are affected by factors that may cause
incompatability and interoperability issues.

5.8 Quality Aspects:

Reliability: Extensive research literature and a collection of commercial tools have been devoted to
testing, ensuring, assuring, and measuring software reliability.
Safety-critical software applications such as telecommunications, aerospace, and medical devices
demand highly reliable software, but although many researchers are reluctant to admit it, most
software currently produced does not need to be highly reliable.

Performance: Performance testing is largely on the basis of load testing, response time, download
time of a web page, or transactions performed per unit time.
Security: We have all heard about Web sites being cracked and private customer information
distributed or held for ransom.
This is only one example of the many potential security flaws in Web software applications. When
the Web functioned primarily to distribute online brochures, security breaches had relatively small
consequences.

Usability: Web application users have grown to expect easy Web transactions—as simple as buying
a product at a store. Although much wisdom exists on how to develop usable software and Web
sites, many Web sites still do not meet most customers’ usability expectations.

Scalability: We must engineer Web software applications to be able to grow quickly in terms of
both how many users they can service and how many services they can offer.
The need for scalability has driven many technology innovations of the past few years.
The industry has developed new software languages, design strategies, and communication and
data transfer protocols in large part to allow Web sites to grow as needed.

Availability: Availability not only means that the web software is available at any time, but in
todays environment it also must be available when accessed by diverse browsers.

Maintainability: One novel aspect of Web-based software systems is the frequency of new
releases. Traditional software involves marketing, sales, and shipping or even personal installation
at customers’ sites. Because this process is expensive, software manufacturers usually collect
maintenance modifications over time and distribute them to customers simultaneously. For a
software product released today, developers will start collecting a list of necessary changes. For a
simple change, (say, changing a button’s label), the modification might be made immediately. But
the delay in releases means that customers won’t get more complex (and likely important)
modifications for months, perhaps years. Web-based software, however, gives customers immediate
access to maintenance updates - both small changes (such as changing the label on a button) and
critical upgrades can be installed immediately.
 5.9 Web Engineering: (WEBE)
• Web engineering is an application of scientific, engineering, and management principles and
disciplined and systematic approaches to the successful development, deployment,
and maintenance of high-quality web-based systems and applications

5.9.1 Analysis and Design of Web Based Systems:

Keeping in consideration the nature of web applications, the design of these systems must
consider the following:
--Design for Usability-Interface, design, navigation
--Design for comprehension
-- Design for Performance
-- Design for Security and Integrity
-- Design for evolution, maintainability
-- Design for testability.

we have to first understand UML-based analysis and design models and then move to testing these systems

Conceptual Modeling:
A conceptual model can be defined as a model which is made of concepts and their relationships.
 A conceptual model is the first step before drawing a UML diagram. 
 It helps to understand the entities in the real world and how they interact with each other.
As UML describes the real time systems it is very important to make a conceptual model and then
proceed gradually.
Conceptual model of UML can be mastered by learning the following three major elements:
 UML building blocks
 Rules to connect the building blocks
 Common mechanisms of UML





Navigation Modeling : The navigation space model specifies, which objects can be visited through
navigation in the hypermedia application.
In the process of building the navigation space model the developer takes design decisions that are
crucial, such as which view of the conceptual model is needed for the application and what
navigation paths are required to ensure the application’s functionality.
The decisions of the designer are based on the conceptual model, use case model and the navigation
requirements that the application must satisfy.
The navigational structure model shows how to navigate through the navigation space by using the
access elements

Presentation Modeling: In the next step of our methodology we describe how the information
within the navigation space and the access structures are presented to the user.
This is done by constructing a presentation model which shows an abstract interface design
similarly to a user interface sketch.
The presentation model focuses on the structural organization of the presentation and not on the
physical appearance in terms of special formats, colors.

Web Scenarios Modeling: The dynamic behaviour of any web scenarios including the navigation
scenarios are modeled here.
The navigation structure model is detailed here showing all the sequences.
This modeling is done with the help of sequence, interaction diagram / collaboration diagrams and
state chart diagrams.

Task Modeling: The task performed by the user or system are modeled here. Basically, the use-
cases as tasks are refined here.
Since use-cases are refined by activity diagrams in UML, these diagrams are used for task
modeling. The modeling elements for task modeling are those for activity diagrams i.e activities,
transitions and branches.

Configuration Modeling: Since web systems are drivers and complex in nature, we need to
consider all the configuration and attributes that may be present on the client as well as on servers.
Deployment diagrams are used for configuration modeling.

5.9.2 Design Activities:

Interface Design: It considers the design of all interfaces recognized in the system including screen
layouts. Interfaces should be designed such that they are flexible, consistent, and readable.

Content Design: Content design is often a type of Web design and development that includes
selecting the right elements and organizing them in a coherent fashion. Content typically includes
text, static and animated graphics, sound and page layout.

Architecture Design: An overall system architecture describes how the network and various
servers (Web servers, application servers and database servers) interact.
 Presentation Design: This design is related to the look and feel of the application. The design
issues are related to layout of the web pages, graphics to be inserted, color schemes, fonts etc..

Navigation Design: Navigational paths are designed such that users are able to navigate from
one place to another in the web application.

5.10 Testing of Web Based Systems:

• WEB-BASED SYSTEM
• The web-based software system consists of a set of web pages and components
• that interact to form a system which executes using web server(s), network, HTTP, and a
browser, and in which user input affects the state of the system
• Web page is the information that can be viewed in a single browser window.
• A website is a collection of web pages.
• A web application is a program that runs as a whole or in part on one or more web servers
and that can be run by users through a website.
Web applications require the presence of web server in simple configurations and multiple servers in
more complex settings. Such applications are called web based applications

• CHALLENGES IN TESTING FOR WEB-BASED SOFTWARE:

• Some of the challenges and quality issues for web-based system are
• --Diversity and complexity: Web applications interact with many components that run on
diverse hardware and software platforms.
• They all interact with diverse back-end engines and other components that are found on the
 web server or other servers
• The client side includes browsers, HTML, embedded scripting languages, and applets.
• The server side includes CGI, JSPs, Java Servlets, and .NET technologies
• ---Dynamic environment: The dynamic aspects are caused by uncertainty in the program
behaviour, changes in application requirements, rapidly evolving web technology itself, and
other factors.
• The dynamic nature of web software creates challenges for the analysis, testing, and
maintenance for these systems.
• ---Very short development time: Clients of web-based systems impose very short
development time, compared to other software or information systems projects. For e.g. an e-
business system, sports website, etc.
• ---Continuous evolution: Demand for more functionality and capacity after the
• system has been designed and deployed to meet the extended scope and
• demands, i.e. scalability issues.
• ---
• Compatibility and interoperability:
• Web applications often are affected by factors that may cause incompatibility and
interoperability issues.
• Various versions of browsers running under a variety of operating systems can be there on the
client side
Interface Testing: The main interfaces are:

--Web server and application server interface

--Application server and database server interface

Interface Testing includes different activities like:

--Check if all the interactions between these servers are executed properly.
--Errors are handled properly.
--If database or web server returns any error message
--Check what happens if user interrupts any transaction in-between?
--Check what happens if connection to web server is reset in between?

Usability Testing: Usability Testing concentrates on testing the web application in user point of
view.
Content checking: Content should be logical and easy to understand.
Check for spelling errors.
Use of dark colors annoys users and should not be used in site theme.
You can follow some standards that are used for web page and content building.
Content should be meaningful.
All the anchor text links should be working properly.
Images should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your task is to
validate all for UI testing

Navigation Testing:
Compatibility Testing: Compatibility of your web site is a very important testing aspect.
Different types of features for compatability are:

 Browser compatibility
 Operating system compatibility
 Mobile browsing

Browser Compatibility
• Some applications are very dependent on browsers. Different browsers have different
configurations and settings that your web page should be compatible with.
• Your web site coding should be cross browser platform compatible.
• We can perform Testing of web application on different browsers like Internet Explorer,
Firefox, Netscape Navigator, AOL, Safari, Opera browsers with different versions.

OS Compatibility:
Some functionality in your web application may not be compatible with all operating systems. All
new technologies used in web development like graphics designs, interface calls like different APIs
may not be available in all Operating Systems. Test your web application on different operating
systems like Windows, Unix, MAC, Linux, Solaris with different OS flavors.

Mobile Browsing:
This is the new technology age. So in future, Mobile browsing will rock. Test your web pages on
mobile browsers.

Security Testing:

Security Test Plan: Securing testing can be planned into two categories:

--1.Testing the security of the infrastructure hosting the Web application and
--2.Testing for vulnerabilities of the web application.
.

Test Scenarios for Security Testing:

1. Verify the web page which contains important data like password, credit card numbers, secret
answers for security question etc should be submitted via HTTPS (SSL).
2. Verify the important information like password, credit card numbers etc should display in
encrypted format.
3. Verify password rules are implemented on all authentication pages like Registration, forgot
password, change password.
4. Verify if the password is changed the user should not be able to login with the old password.
5.Verify the error messages should not display any important information.
6. Verify if the user is logged out from the system or user session was expired, the user should not
be able to navigate the site.
 7. Verify to access the secured and non secured web pages directly without login.
8.Verify the ―View Source code‖ option is disabled and should not be visible to the user.
9. Verify the user account gets locked out if the user is entering the wrong password several
times.
10. Verify the cookies should not store passwords.

Performance Testing:
Performance testing is conducted to evaluate the compliance of a system or component with
specified performance requirements.
General Test scenarios:
 To determine the performance, stability and scalability of an application under different load
conditions.
 To determine if the current architecture can support the application at peak user levels.
 To determine which configuration sizing provides the best performance level.
 To identify application and infrastructure bottlenecks.
 To determine if the new version of the software adversely had an impact on response time.
 To evaluate product and/or hardware to determine if it can handle projected load volumes.

Performance Parameters:
--Resource utilization:The percentage of time a resource Ex:CPU,Memory etc is busy
--Throughput :The number of event responses that have been completed over a given interval of
time
--Response time: the time lapsed between a request and its reply
--Database load: the number of times database is accessed over a given interval of time
--Scalability: the ability of an application to handle additional workload
--Round trip time:The time taken to complete the entire user workload

Types of Performance Testing:

-- Load Testing:

Stress Testing
5.11 Testing mobile systems:
Mobile application testing is a process by which application software developed for hand held
mobile devices is tested for its functionality, usability and consistency. Mobile application testing
can be automated or manual type of testing. Mobile applications either come pre-installed or can be
installed from mobile software distribution platforms. Mobile devices have witnessed a phenomenal
growth in the past few years.

Key Challenges in Mobile Application Testing:

1. Variety of Mobile Devices: Mobile devices differ in screen sizes, input methods (QWERTY,
touch, normal) with different hardware capabilities.

2. Diversity in Mobile Platforms/OSes: There are different mobile operating systems in the
market. The major ones are Android, iOS, Symbian, Windows Phone, and BlackBerry(RIM).
3. Each operating system has its own limitations. Testing a single application across multiple devices
running on the same platform and every platform poses a unique challenge for testers.

4. Device Availability: Access to the right set of devices when there is an ever-growing list of
devices and operating system versions is a constant mobile application testing challenge. Access to
devices can become even more challenging if testers are spread across different locations.

5. Mobile network operators: There are over 400 mobile network operators in the world;out of
which some are CDMA, some GSM.

6. Scripting: The variety of devices makes executing a test script (scripting) a key challenge. As
devices differ in keystrokes, input methods, menu structure and display properties single script does
not function on every device.

7. Choosing how to test: There are two main ways of testing mobile applications: testing on real
devices or testing on emulators. Unfortunately, neither method is flawless.[5] Emulators often miss
issues that can only be caught by testing on real devices, but because of the multitude of different
devices in the market, real devices can be expensive to purchase and time-consuming to use for
testing.

Types of Mobile Application Testing:

1. Functional Testing: Functional testing ensures that the application is working as per the
requirements. Most of the test conducted for this is driven by the user interface and call flows.

2. Laboratory Testing: Laboratory testing, usually carried out by network carriers, is done by
simulating the complete wireless network. This test is performed to find out any glitches when a
mobile application uses voice and/or data connection to perform some functions.

3. Performance Testing: This testing process is undertaken to check the performance and behavior
of the application under certain conditions such as low battery, bad network coverage, low available
memory, simultaneous access to application’s server by several users and other conditions.

4. Memory Leakage Testing: Memory leakage happens when a computer program or application is
unable to manage the memory it is allocated resulting in poor performance of the application and
the overall slowdown of the system.

As mobile devices have significant constraints of available memory, memory leakage testing is
crucial for the proper functioning of an application

5. Interrupt Testing: An application while functioning may face several interruptions like
incoming calls or network coverage outage and recovery. The different types of interruptions are:
 Incoming and Outgoing SMS and MMS
 Incoming and Outgoing calls
 Incoming Notifications
 Battery Removal
 Cable Insertion and Removal for data transfer

6. Usability testing: Usability testing is carried out to verify if the application is achieving its goals
and getting a favorable response from users. This is important as the usability of an application is
its key to commercial success (it is nothing but user friendliness).

7. Installation testing: Certain mobile applications come pre-installed on the device whereas others
have to be installed from the store.

Installation testing verifies that the installation process goes smoothly without the user having to
face any difficulty.
This testing process covers installation,
updating and uninstalling of an application.
8.Security testing

 If an app is vulnerable to security threats, people hardly use that app. So, you have to ensure the
credibility of your app by performing security testing services.

9.Recover-ability Testing

 Recovery ability testing mainly checks how an app works on transactions when there is an app
failure, and also analyses whether the system (be it mobile or desktop) recovers the data after
suspended connections.

11. Compatibility Testing

Compatibility Testing is performed on mobile phones to know whether the app works on different
devices.
 5.12 Testing Object Oriented Software
Basics:

Terminology:

Object: An entity that has state and behaviour is known as an object e.g. chair, bike, marker, pen,
table, car etc. It can be physical or logical (tangible and intangible).
An object has three characteristics:

 state: represents data (value) of an object.

 Behaviour: represents the behaviour (functionality) of an object such as deposit, withdraw
etc.
 Identity: Object identity is typically implemented via a unique ID. The value of the ID is
not visible to the external user. But,it is used internally by the JVM to identify each object
uniquely.
Class:
A class is a group of objects that has common properties. It is a template or blueprint from which
objects are created.
A class in java can contain:

 data member
 method
 constructor
 block
 class and interface
Inheritance: It is a strong feature of OOT. It provides the ability to derive new class from existing
classes.

The derived class inherits all the data and behavior (operations) of the original base class. Moreover,
derived class can also add new features, e.g. employee is the base class and we can derive manager as
derived class..

Polymorphism: Polymorphism means having many forms and implementations of a particular

functionality.
For example: to convince the customer differently, to draw something e.g. shape or rectangle etc .
 Abstraction: Hiding internal details and showing functionality is known as abstraction.

A good abstraction is one that emphasizes details that are significant to the user and suppresses details
that are immaterial to him’.
For example: phone call, we don't know the internal processing.

Encapsulation: Binding (or wrapping) code and data together into a single unit is known as
encapsulation.
Encapsulation avoids the accidental change in data such that no one can directly access the object’s data
For example: capsule, it is wrapped with different medicines.
5.13 Object-Oriented Modeling and UML:
UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts
of software systems. UML was created by Object Management Group (OMG) and UML 1.0
specification draft was proposed to the OMG in January 1997. OMG is continuously putting effort
to make a truly industry standard.
--UML stands for Unified Modeling Language.
--UML is different from the other common programming languages like C++, Java, COBOL etc.
--UML is a pictorial language used to make software blue prints.
So UML can be described as a general purpose visual modeling language to visualize, specify,
construct and document software system.
Although UML is generally used to model software systems but it is not limited within this
boundary. It is also used to model non software systems as well like process flow in a
manufacturing unit etc.

UML is not a programming language but tools can be used to generate code in various languages
using UML diagrams.
UML has a direct relation with object oriented analysis and design.
After some standardization UML is become an OMG (Object Management Group) standard.
User View:
The UML user model view encompasses the models which define a solution to a problem as
understood by the client or stakeholders. This view is often also referred to as the Use Case or
scenario view.

Structural View:
The UML structural view encompasses the models which provide the static, structural
dimensions and properties of the modelled system. This view is often also referred to as the static
or logical view. particular point in time.

Behavioural View:
These UML models describe the behavioural and dynamic features and methods of the modelled
system. This view is often also referred to as the dynamic, process, concurrent or collaborative
view. after completion of the elements as flows of processing within a system.

ImplementationView:
The UML Implementation View combines the structural and behavioural dimensions of the solution
realisation or implementation. The view is often also referred to as the component or development
view.
Environment View:
These UML models describe both structural and behavioural dimensions of the domain or
environment in which the solution is implemented. This view is often also referred to as the
deployment or physical view.

Use Case Model: These models depict the functionality required by the system and the interaction
of users and other elements (known as actors) with respect to the specific solution.

Use Case: A Use Case is a scenario that identifies and describe how the system will be used in
given situation.

Actors: Use Cases are typically related to 'actors', which are human or machine entities that use or
interact with the system to perform a piece of meaningful work that helps them to achieve a goal.
 Class Diagrams: These models describe the static structure and contents of a system using
elements such as classes, packages and objects to display relationships such as containment,
inheritance and associations.

Object Diagrams: An object diagram represents the static structure of the system at a particular
instance of time.

Class-responsibility-collaboration ( CRC) diagrams This diagram represents a set of classes and the
interaction between them using associations and messages sent and received by the classes

Sequence Diagram: Describe timing sequence of the objects over a vertical time dimension with
interactions between objects depicted on a horizontal dimension.
Collaboration Diagrams: Describe the interactions and relationships between objects and
sequences of a system organised in time and space. Numbers are used to show the sequence of
messages.

State Diagrams: Describe the sequence, status conditions and appropriate responses or actions to
conditions during the life of the objects within the system.

Activity Diagrams: Describe the methods, activities and resulting transitions

 Component Diagrams: These depict the high level organisation and dependencies of source code
components, binary components and executable components and whether these components exist at
compile, link or run time.

Deployment Diagrams: These UML Models depict and describe the environmental elements and
configuration of runtime processing components, libraries and objects that will reside on them.

5.14 Object Oriented Testing:

• 5.14.1 CONVENTIONAL TESTING AND OOT:

• The difference between unit testing for conventional software and object-oriented software
arises from the nature of classes and objects
•

5.14.2 OBJECT-ORIENTED TESTING AND MAINTENANCE PROBLEMS

• it is not easy to understand and test and maintenance the OO software

• David et al have recognized some of these problems which are:

Understanding problem: The encapsulation and information hiding features are not easily understood
the very first time.
Dependency problem: The dependency problem is mainly due to complex relationships, e.g.
inheritance, aggregation, association.
State behaviour problem: The effect of an operation on an object also depends on the state of the
object and may change its state.

5.14.3 ISSUES IN OO TESTING

The following are some issues which come up while performing testing on OO software

 Basic unit for testing

  Implications of inheritance
 Polymorphism
 White-box testing
 Black-box testing
 Integration strategies

Basic unit for testing There is nearly universal agreement that class is the natural
unit for test case design. Other units for testing are aggregations of classes: class clusters, and application
systems. The intended use of a class implies different test requirements, e.g., application-specific vs
general-purpose classes, abstract classes, and parameterized (template) classes. Testing a class instance
(an object) can verify a class in isolation. However, when verified classes are
used to create objects in an application system, the entire system must be tested as a whole before it can
be considered verified.

Implications of inheritance In case of inheritance, the inherited features require retesting because these
features are now in, new context of usage. Therefore, while planning to test inheritance, include all
inherited features. Moreover, planning should also consider the multiple contexts of usage in
case of multiple inheritances.

Polymorphism In case of polymorphism, each possible binding of a polymorphic component requires a

separate test to validate all of them. However, it may be hard to find all such bindings. This again
increases the chance of errors and poses an obstacle in reaching the coverage goals.

White-box testing There is also an issue regarding the testing techniques for OO software. The issue is
that the conventional white-box techniques cannot be adapted for OO software. In OO software, class is
the major component to be tested, but conventional white-box testing techniques cannot be applied on
testing a class. These techniques may be applicable to individual methods but not suitable for OO
classes.

Black-box testing The black-box testing techniques may be suitable to OO software for conventional
software, but sometimes re-testing of inherited features require examination of class structure. This
problem also limits the blackbox methods for OO software.

Integration strategies Integration testing is another issue which requires attention and there is need to
devise newer methods for it. However, there is no obvious hierarchy of methods or classes. Therefore,
conventional methods of incremental integration testing cannot be adopted.

5.14.4 STRATEGY AND TACTICS OF TESTING OOS

The strategy for testing OOS is same as verification and validation activities in procedural software

Tactics for testing may differ depending upon the structure of OOS.

Object-oriented software testing is generally done bottom-up at four levels:

 Method-level testing (unit testing):

It refers to the internal testing of an individual method in a class. Existing testing techniques for
conventional programming languages are fully applicable to method-level testing.

 Class-level testing (unit testing):

 Methods and attributes make up a class. Class-level or (intra-class) testing refers to the testing of
interactions among the components of an individual class.

 Cluster-level testing (Integration testing):

Cooperating classes of objects make up a cluster. Clusterlevel (or inter-class) testing refers to the testing of
interactions among objects
 System-level testing:
Clusters make up a system. System-level testing is concerned with the external inputs and outputs visible
to the users of a system.

5.14.5 VERIFICATION OF OOS

The verification process is different in analysis and design steps. Since OOS is largely dependent on
OOA and OOD models.

Verification of OOA and OOD models

• 􀂄 Assess the class-responsibility-collaborator ( CRC) model and object relationship diagram.
• 􀂄 Review system design
• 􀂄 Test object model against the object relationship
• 􀂄 Review detailed specifications of algorithms used to implement operations using conventional
inspection techniques.

Verification points of some of the models:

 Check that each model is correct ie., symbology, conventions

 Check that each use-case is feasible in the system.
 Check that a specific use-case needs modification
 Check that actors identified in use-case model are able to cover the functionality of the whole
system.
 All events and their sequences must be checked iteratively in a sequence diagram
 Collaboration diagrams must be verified for distribution of processing between objects

5.14.6 VALIDATION ACTIVITIES

Unit/Class Testing:
Unit or module testing has no meaning in the context of OOS
OOS is based on the concept of class and objects.
the smallest unit to be tested is a class.
The nature of OOS is different as compared to procedural software;
therefore many issues rise for testing a class
Issues in testing a class

 A class cannot be tested directly

 the methods should also be tested with reference to a class or class hierarchy in the direction
of complete testing of a class.
 One important issue in class testing is the testing of inheritance


• Following special cases also apply to inheritance testing:

• (a) Abstract classes can only be tested indirectly.
• (b) Special tests have to be written to test the inheritance mechanism

• There may be operations in a class that change the state of the object on their execution
• Polymorphism provides us with elegant compact code, but it can also make testing more
complicated.
• The identification of all the paths through a section of code that uses polymorphism is harder

5.14.7 TESTING OF OO CLASSES

1.Feature-based Testing of Classes

The features of a class can be categorized into six main groups

• ---Create:
• These are also known as constructors
• ---- initial memory allocation to the object,

• ----Destroy:
• These are also known as destructors.
• -- memory de-allocation

• ----Modifiers:

• The features in this category alter the current state of the object
• ---Predicates:
• The features in this category test the current state of the object for a specific instance
• ---Selectors:
• The features in this category examine and return the current state of the object
• ----Iterators:
• The features in this group are used to allow all required sub-objects to be visited in a defined
order
 • Testing feature groups:
• guidelines for the preferred features to be tested:
• (i) The create features of a class must be verifi ed fi rst
• (ii) The selector features can be the next features to be verifi ed
• (iii) The predicate features of a class test for specifi c states of the object
• (iv) The modifi er features of a class are used to alter the state of the object from one valid state
to another
• (v) The destructor feature of a class performs any ‘housekeeping’, for example, returning any
allocated memory to the heap

Role of Invariants in Class Testing

 An invariant in Object-Oriented programming refers to some set of conditions or

assertions that need to hold throughout the life of an object of a class
 These assertions need to hold from the time the constructor is called for an object, at the
end of each member (mutator) method call to the end of the destructor call.

Turner and Robson have also shown the importance of invariants in class testing.

For example, take a class to implement an integer Stack as:

Class Stack with following data members:
ItemCount, empty, full, push, pop, max_size

Here in this class, invariants can be defi ned as given below:

1. ItemCount cannot have a negative value.
2. There is an upper bound check on ItemCount, i.e. ItemCount <=maxsize
3. Empty stack, i.e. ItemCount = 0
4. Full Stack, i.e. ItemCount = max_size

• These invariants allow the validity of the current state of the object to be tested easily.
• An invariant is also useful for ensuring that the data representation is in a valid
state, even if it has been directly altered.
• This can help maintain the integrity of the class.

1)State-Based Testing
• State-Based Testing:
• State-based testing can also be adopted for testing of object-oriented programs
• The systems can be represented naturally with finite state machines as states correspond to certain values
of the attributes and transitions correspond to methods
• State-based testing tests these interactions by monitoring the effects that features have on the state of an
object.
• The state can be determined by the values stored in each of the variables that constitute its data
representation.
• Each separate variable is known as a substate, and the values it may store are known as substate-values.
• The restrictions on objects:
• 􀂄 The behaviour of the object can be defi ned with a fi nite number of
• states.
• 􀂄 There are a finite number of transitions between the states.
• 􀂄 All states are reachable from the initial state.
• 􀂄 Each state is uniquely identifiable through a set of methods
State-based testing based on the finite state automata. tests each feature with all its valid input states

State-based testing based on the finite state automata. each feature with all its valid input states.
For designing the test cases

For designing the test cases:

 The test cases consist of applying each stimulus in combination with each possible state for the
representation.
 The resultant states generated are then validated against those expected.
 The behaviour of an object can be predicted by matching the input states expected by one feature with
the output states of another.

Process of state-based testing

The process of using state-based testing techniques

is as follows:
1. Defines the states.
2. Define the transitions between states.
3. Define test scenarios.
4. Define test values for each state.

the Stack example :

1.Define states The first step in using state-based testing is to defi ne the states.
We can create a state model with the following states in the Stack example:
1. Initial: before creation
2. Empty: ItemCount = 0
3. Holding: ItemCount > 0, but less than the max capacity
4. Full: ItemCount = max
5. Final: after destruction

2.Define transitions between states

1. Initial  Empty:
Action = “create” e.g. “s = new Stack()” in Java
2. Empty Holding:
Action = “add”
3. Empty Action = “add” if max_size= 1
4. EmpFinal:
Action = “destroy” e.g. destructor call in C++, garbage collection in Java
5. Holding Empty:
Action = “delete” Full:

List for each identified state

a) Valid actions (transitions) and their effects
b) Invalid actions that should produce an exception

3.Define test scenario Tests generally consist of scenarios that exercise the object
along a given path through the state machine. The following are some guidelines:
1. Cover all identified states at least once.
2. Cover all valid transitions at least once.
3. Trigger all invalid transitions at least once

4.Define test values for each state :choose test values for each individual state.

2) INHERITANCE TESTING

The issues in testing the inheritance feature

• Superclass modifications
• Inherited methods
• Reusing of test suite of superclass
• Addition of subclass method
• Change to an abstract superclass interface
• Interaction among methods
• Inheritance of Invariants of Base Class

Superclass modifications When a method is changed in superclass, the following should be considered:
(i) The changed method and all its interactions with changed and unchanged methods must be retested
in the superclass.
(ii) The method must be retested in all the subclasses inheriting the method as extension.
(iii) The ‘super’ references to the method must be retested in subclasses.
Inherited methods The following inherited methods should be considered for testing:
(i) Extension: It is the inclusion of superclass features in a subclass, inheriting method implementation
and interface (name and arguments).
(ii) Overriding: It is the new implementation of a subclass method, with the same inherited interface as
that of a superclass method.
Reusing of test suite of superclass It may not be possible to reuse superclass
tests for extended and overridden methods due to the following reasons:
(i) Incorrect initialization of superclass attributes by the subclass.
(ii) Missing overriding methods.
(iii) Direct access to superclass fields from the subclass code can create a subtle side.
(iv) A subclass may violate an invariant from the superclass or create an invalid state.

Addition of subclass method When an entirely new method is added to a specialized subclass, the
following should be considered:
(i) The new method must be tested with method-specifi c test cases.
(ii) Interactions between the new method and the old methods must be tested with new test cases.
Interaction among methods To what extent should we exercise interaction among methods of all
superclasses and of the subclass under test?
Thus, inherited methods should be retested in the context of a subclass.
Example: If we change some method m() in a superclass, we need to retest m()
inside all subclasses that inherit it.
Example: If we add or change a subclass, we need to retest all methods inherited
from a superclass in the context of the new/changed subclass

Inheritance of Invariants of Base Class

If an invariant is declared for a base class, the invariant may be extended by the derived class.
If the invariant provided by the base class is retracted, then the base class must be retested with respect
to the new invariant.

3) Incremental Testing

The technique first defines inheritance with an incremental hierarchy structure.

this approach is used to test the inheritance of classes

This technique is based on the approach of a modifier to define a derived class.
The following attributes have been identified:
􀂄New attribute
􀂄Inherited attribute
􀂄Redefined attribute
􀂄Virtual-new attribute
􀂄Virtual-inherited attribute
􀂄Virtual-redefined attribute
The following steps describe the technique for incremental testing:

1.Test the base class by testing each member function individually and then testing the interactions among the
member functions
2.For every derived class, determine the modifier m and make a set M of all features for all derived classes
3.For every feature in M, look for the following conditions and perform testing:
(i) If feature is new or virtual-new
(ii) If feature is inherited or virtual-inherited without any affect
(iii) If feature is redefined or virtual-redefined

INTEGRATION TESTING
Different classifications of testing levels have been proposed with the following terminology:

1.Inter-class testing
2.Cluster testing
3.Inter-cluster testing
4.Thread-based Integration Testing
a thread can be seen as a scenario of normal usage of an object-oriented system

Testing a thread implies testing the interactions between classes according to a specific sequence of
method invocations.

integration level thread is a MM-path.

Jorgensen and Erickson identify two different levels for integration testing:
Message quiescence This level involves testing a method together with all methods it invokes, either directly or
transitively.
Event quiescence This level is analogous to the message quiescence level, with the difference that it is driven by
system-level events.
Implicit Control Flow-based Integration Testing

There are three approaches for this type of integration:

optimistic,
pessimistic
and balanced

Optimistic approach This approach is based on the optimistic view that method invocation
will be confined to the level of abstraction of the source code only.
Therefore, in this type of integration we will test only those method invocation or interfaces which support this
abstraction.

Pessimistic approach This approach assumes that every class can call the
common method CalSalary()

Balanced approach This approach is a balance between the above two approaches
We must take the interfaces according to the code as well as expected method invocations
5.15 UML-BASED OO TESTING
UML is a design and modeling language for object-oriented software
It supports facilities both for abstract high level modeling and for more detailed low-level modeling

UML also provides support for model-based testing

UML diagrams in software testing

The following UML diagrams are helpful in the testing activities mentioned
below:
􀂄Use-case diagrams: testing of system-level functional requirements, acceptance testing
􀂄Class diagrams: class (module / unit) testing, integration testing
􀂄Sequence diagrams, collaboration diagrams: integration testing, testing of control and interaction between
objects, testing of communication protocols between (distributed) objects
􀂄Activity diagrams: testing of work fl ow and synchronization within the system, white-box testing of control
flow
􀂄State diagrams (state charts): state-based testing
􀂄Package diagrams, component diagrams: integration testing
􀂄Deployment diagrams: system testing

System Testing based on Use-Cases

Use-case: a use-case is a sequence of interactions

Scenario: It is an instance of a use-case

Use-case model: This is a set of use-case diagrams,

For testing, the use-case model must be extended

with:
􀂄the domain of each variable participating in the use-cases,
􀂄the input/output relationships among the variables,
􀂄the relative frequency of the use-cases,
􀂄the sequential (partial) order among the use-cases.

To perform this testing, the tester needs to identify four things:

􀂄the use-cases of interest,
􀂄the actors involved in using the system,
􀂄the input, output, and system effects for the use-cases,
􀂄the flows of interest between the use-cases.