0% found this document useful (0 votes)
5 views73 pages

CH 2

The document outlines various types and levels of software testing, including unit testing, integration testing, system testing, and acceptance testing. It describes the roles of drivers and stubs in testing, the importance of non-functional testing types such as performance, security, and usability testing, and the strategies for integration testing. Additionally, it emphasizes the significance of regression and compatibility testing to ensure software quality and reliability.

Uploaded by

kutesanika21
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views73 pages

CH 2

The document outlines various types and levels of software testing, including unit testing, integration testing, system testing, and acceptance testing. It describes the roles of drivers and stubs in testing, the importance of non-functional testing types such as performance, security, and usability testing, and the strategies for integration testing. Additionally, it emphasizes the significance of regression and compatibility testing to ensure software quality and reliability.

Uploaded by

kutesanika21
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 73

Chapter-02

Types & Levels of Testing


Prepared By,
Mr.S.H.Sangale
Levels of Testing
Unit testing
• Unit testing involves individually testing unit
of code separately to make sure that it works
on its own, independent of the other units.
• Unit testing is a software development
process in which the smallest testable parts of
an application, called units, are individually
and independently exercised for proper
operation.
• without affecting the functioning of other units or
the program as a whole
• Unit testing is an action used to validate that
separate units of source code.
• It is also called as module test.
• It focuses on functionality.
• It is done before system integration.
• Main goal is to isolate the smallest unit to check
whether behave as expected.
• It is executed by the Developer.
• Before integration each unit is tested separately.
• Example: - A function, method, Loop or statement
in program is working fine.
• Concentrates on the internal processing logic and
data structures
• Allows errors to be more easily predicted
• Concentrates on critical modules and those with
high cyclomatic complexity
• Unit testing can be time-consuming and tedious.
• It helps to produce high quality code
Unit Testing
Unit Testing
Driver
• Drivers are testing tool used to control and
operate the software being used.
• For Testing modules, it may require some inputs
are to be received from another module, this
module passes inputs to the module to be tested
is not ready and under development.
• Suppose you are testing the software that
requires large amount of data to enter for
execution.
• you could replace the keyboard and mouse of
system being tested with additional computer
• ‘Driver’ is a piece of software that drives the Unit
being tested. I.e. A piece of code that passes test
cases to another piece of code
• A driver creates necessary ‘Inputs’ required for
the Unit and then invokes the Unit
• Driver is called component
• They control or operate the software being tested
• Used in the Bottom –Up Test strategy
stub
• Stubs are opposite of driver.
• They don’t control or operate the software being
tested.
• They instead receive or respond to data that the
software sends.
• Suppose you are testing software that sends data to
a printer. To test we can enter data , print it and
look at resulting paper but it is inefficient method.
• But if you replace printer with another computer
that running stub software that could read and
interpret the data.
• It is much more feasible and quick to test
software.
• stubs are programs that simulate the behaviors of
software components (or modules) that a module
undergoing tests depends on.
• ‘Stub’ is a piece of software that works similar to a
unit which is referenced by the Unit being tested,
but it is much simpler that the actual unit
• dummy modules required to simulate for testing,
instead of actual modules. These are called stubs.

• i.e. A piece of code that simulates the activity of


missing components
• A Stub works as a ‘Stand-in’ for the subordinate
unit and provides the minimum required behavior
for that unit
• Stub is calling Component
• Used in the Top – Down Testing Strategy
• Stubs and drivers are used to replace the missing
software and simulate the interface between the
software components in a simple manner.
• For testing module independently we require
stub and driver.
• Both are temporary program written for testing
purpose.
Integration Testing
• It is logical extension of unit testing.
• Two units already have been tested are combined and test.
• Integrate more than one unit up to whole system.
• Idea is to test small pieces and eventually expand the process
to test your module with other group.
• Integration testing identifies the problem that occur when
units are combined.
Decomposition based Testing

• There are following strategies


• Top Down Integration
• Bottom Up Integration
• Bi-Directional Integration
• Incremental Integration
• Non- Incremental Integration
Non-incremental
Non-incremental
• All the software units are assembled into the entire
program.
• This assembly is then tested as a whole from the
beginning.
• Cause of defects are not easily isolated and
corrected.
• The non incremental approach is also known as
“Big-Bang” testing. This approach is very
unfashionable due to the level of risk that one takes
in hoping that the system will perform as expected.
Incremental Integration
Incremental Integration

• The program is constructed and tested in


small increments by adding a minimum
number of components at each interval.
• Therefore errors are easier to isolate and
correct.
• Interfaces are tested completely
Top-down Testing
• The top down testing requires highest level
module to test and integrated first.
• Modules are integrated from the main module
to subordinate module.
• In Top-down Testing, higher level modules are
tested. If lower modules required to make up
the system are not yet available then, stubs
are used to simulate their activity.
Bottom-up testing
• The bottom- up testing requires the lowest
level units to be tested and integrated first.
• Lowest level sub-module are integrated and
test then successively upper level components
are added and tested.
• In Bottom-up testing, lower level modules are
tested. If the higher level modules required to
make up the sysused to simulate their tem are
not yet available then, drivers are activity.
Bi-directional Testing
• It is combination of Top down and Bottom up
integration testing
• Known as sandwich testing.
System Testing
System Testing
• System Testing (ST) is a black box testing technique
performed to evaluate the complete system against
specified requirements.
• In System testing, the functionalities of the system are
tested.
• It concentrates on testing the complete system.
• Against objectives of the system
• In many different environment with various versions and
operating systems.
• System testing test all components of the system.
• Testing the interaction with other parts of the
system to validate and verify functional
specifications.

• Usability testing , Functional testing , performance


testing , security testing ,regression testing are used.

• System testing should investigate both functional and


non-functional requirements of the testing.
Recovery Testing
• In software testing, recovery testing is the activity
of testing how well an application is able
to recover from crashes, hardware failures and other
similar problems.
• It is done to check how fast and better the application
can recover against any type of crash.
• Recovery testing is an extension to Error handling
testing.
• It is also known as reliability testing where test engineer
can test whether application can recover from
abnormal situation
• Ex. During power failure, network disconnect, server
• It is a type of non-functional testing.
• Recovery testing is done in order to check how fast and
better the application can recover after it has gone through
any type of crash or hardware failure etc.
• Recovery testing is the forced failure of the software in a
variety of ways to verify that recovery is properly performed.
For example, when an application is receiving data from a
network, unplug the connecting cable. After some time, plug
the cable back in and analyze the application’s ability to
continue receiving data from the point at which the network
connection was broken. Restart the system while a browser
has a definite number of sessions and check whether the
browser is able to recover all of them or not.
Security testing
• It is a type of non-functional testing.
• Security testing is basically a type of software testing that’s done to check
whether the application or the product is secured or not. It checks to see if
the application is vulnerable to attacks, if anyone hack the system or login to
the application without any authorization.
• It is a process to determine that an information system protects data and
maintains functionality as intended.
• The security testing is performed to check whether there is any information
leakage in the sense by encrypting the application or using wide range of
software’s and hardware’s and firewall etc.
• Software security is about making software behave in the presence of a
malicious attack.
• The six basic security concepts that need to be covered by security testing
are: confidentiality, integrity, authentication, availability, authorization and
non-repudiation.
Performance testing
• It is a type of non-functional testing.
• Performance testing is testing that is performed, to determine how fast some aspect of
a system performs under a particular workload.
• It can serve different purposes like it can demonstrate that the system meets
performance criteria.
• It can compare two systems to find which performs better. Or it can measure what part
of the system or workload causes the system to perform badly.
• This process can involve quantitative tests done in a lab, such as measuring the
response time or the number of MIPS (millions of instructions per second) at which a
system functions.
• Why to do performance testing:
• Improve user experience on sites and web apps
• Increase revenue generated from websites
• Gather metrics useful for tuning the system
• Identify bottlenecks such as database configuration
• Determine if a new release is ready for production
• Provide reporting to business stakeholders regarding performance against expectations
Load testing
• Load testing is a type of non-functional testing.
• A load test is type of software testing which is conducted to understand the behavior of the application
under a specific expected load.
• Load testing is performed to determine a system’s behavior under both normal and at peak conditions.
• It helps to identify the maximum operating capacity of an application as well as any bottlenecks and
determine which element is causing degradation. E.g. If the number of users are increased then how
much CPU, memory will be consumed, what is the network and bandwidth response time.
• Load testing can be done under controlled lab conditions to compare the capabilities of different
systems or to accurately measure the capabilities of a single system.
• Load testing involves simulating real-life user load for the target application. It helps you determine how
your application behaves when multiple users hits it simultaneously.
• Load testing differs from stress testing, which evaluates the extent to which a system keeps working
when subjected to extreme work loads or when some of its hardware or software has been
compromised.
• The primary goal of load testing is to define the maximum amount of work a system can handle without
significant performance degradation.
• Examples of load testing include:
– Downloading a series of large files from the internet.
– Running multiple applications on a computer or server simultaneously.
– Assigning many jobs to a printer in a queue.
– Subjecting a server to a large amount of traffic.
– Writing and reading data to and from a hard disk continuously.
• It is a type of non-functional testing.
• It involves testing beyond normal operational capacity, often
to a breaking point, in order to observe the results.
• It is a form of software testing that is used to determine the
stability of a given system.
• It put greater emphasis on robustness, availability, and error
handling under a heavy load, rather than on what would be
considered correct behavior under normal circumstances.
• The goals of such tests may be to ensure the software does
not crash in conditions of insufficient computational
resources (such as memory or disk space).
Volume testing
• It is a type of non-functional testing.
• Volume testing refers to testing a software application or the
product with a certain amount of data. E.g., if we want to volume
test our application with a specific database size, we need to
expand our database to that size and then test the application’s
performance on it.
• “Volume testing” is a term given and described in Glenford
Myers’ The Art of Software Testing, 1979. Here’s his
definition: “Subjecting the program to heavy volumes of data. The
purpose of volume testing is to show that the program cannot
handle the volume of data specified in its objectives” – p. 113.
• The purpose of volume testing is to determine system
performance with increasing volumes of data in the database.
• Volume Testing = Large amounts of data
Load Testing = Large amount of users
Stress Testing = Too many users, too much
data, too little time and too little room
Regression testing
• What is Regression testing in software?
• Regression testing: During confirmation testing the defect got fixed and
that part of the application started working as intended.
• But there might be a possibility that the fix may have introduced or
uncovered a different defect elsewhere in the software.
• The way to detect these ‘unexpected side-effects’ of fixes is to do
regression testing.
• The purpose of a regression testing is to verify that modifications in the
software or the environment have not caused any unintended adverse
side effects and that the system still meets its requirements.
• Regression testing are mostly automated because in order to fix the
defect the same test is carried out again and again
• it will be very tedious to do it manually.
• Regression tests are executed whenever the software changes, either as
a result of fixes or new or changed functionality.
Compatibility testing
• Software compatibility testing means checking that
your software interacts with and shares information
correctly with other software.
Compatibility Testing means checking whether
software interacts and shares information correctly
with different operating systems, hardware and
software configurations available.
• This interaction could occur between two programs
• simultaneously running on the same computer or
even on different computers connected
• through the Internet thousands of miles apart
• Examples of compatible software are
• Cutting text from a Web page and pasting it into
a document opened in your word processor
• Saving accounting data from one spreadsheet
program and then loading it into a completely
different spreadsheet program
• Having photograph touchup software work
correctly on different versions of the same
operating system
• There are two types of compatibility:
• 1. Backward compatibility testing: it will work
with previous versions of the software.
• 2. Forward compatibility testing: it will work
with Future invented versions of the software.
Data Sharing Compatibility

1. File save and file load


2. File export and file import
3. Cut, copy, and paste
Usability Testing:
• The means that you use to interact with a software program is called its user interface
seven important traits common to a good UI.
• Follows standards and guidelines
your software follows existing standards and guidelines
• Intuitive
Is the user interface clean, unobtrusive, not busy?
Is the UI organized
Is there excessive functionality?
• Consistent
Shortcut keys and menu selections.
Terminology and naming
• Flexible
Flexible software provides more options and more ways to accomplish
the same task
• Comfortable
Software should look and feel proper
A program should warn users before a critical operation
• Correct
WYSIWYG (what you see is what you get).
• Useful
whether it’s useful

• This testing is related to a system’s presentation rather than


its functionality. It helps to find human factors or usability
problems on the system. To adapt according to the actual
work styles rather than forcing the user to adapt according
to the software
• Usability testing identifies discrepancies between the user
interfaces of a product and the human engineering
requirements of its potential users.
• It tests how easy software easy to us/learn and convenient
to the end use.
Acceptance testing
• Acceptance testing is a test conducted to
determine if the requirements of a specification or
contract are met.
• The goal of acceptance testing is to establish
confidence in the system.
• Acceptance testing is most often focused on a
validation type testing.
• enable the user, customers or other authorized
entity to determine whether or not to accept the
system.
Types of Acceptance testing

User acceptance testing


• This may include factory acceptance testing, i.e. the testing
done by factory users before the product or system is
moved to its destination site, after which site acceptance
testing may be performed by the users at the site.
Operational acceptance testing
• Also known as operational readiness testing, this refers to
the checking done to a system to ensure that processes
and procedures are in place to allow the system to be used
and maintained. This may include checks done to back-up
facilities, procedures for disaster recovery, training for end
users, maintenance procedures, and security procedures.
Contract and regulation acceptance testing
• In contract acceptance testing, a system is tested against
acceptance criteria as documented in a contract, before
the system is accepted. In regulation acceptance testing,
a system is tested to ensure it meets governmental, legal
and safety standards.
Alpha and Beta testing
• Alpha testing takes place at developers' sites, and
involves testing of the operational system by internal
staff, before it is released to external customers. Beta
testing takes place at customers' sites, and involves
testing by a group of customers who use the system at
their own locations and provide feedback, before the
system is released to other customers. The latter is often
called “field testing”.
Alpha testing
• Alpha testing, the software is tested by in-house
developers during which the goal is to catch bugs
quickly.
• In the second phase of alpha testing, the software
is given to the software QA team for additional
testing.
• Alpha testing is a form of internal acceptance
testing, before the beta testing is performed.
• performed to identify all possible issues/bugs
before releasing the product to everyday users
or public
• The focus of this testing is to simulate real
users by using blackbox and whitebox
techniques.
Beta Testing
• Beta Testing of a product is performed by "real
users" of the software application in a "real
environment" and can be considered as a form of
external user acceptance testing.

• Beta version of the software is released to a limited


number of end-users of the product to obtain
feedback on the product quality. Beta testing
reduces product failure risks and provides increased
quality of the product through customer validation.
• It is the final test before shipping a product to
the customers.
• Direct feedback from customers is a major
advantage of Beta Testing.
• This testing helps to tests the product in real
time environment.
Alpha Testing Beta Testing
Alpha testing performed by Testers who Beta testing is performed by Clients or
are usually internal employees of the End Users who are not employees of
organization the organization
Alpha Testing performed at developer's Beta testing is performed at client
site location or end user of the product

Reliability and security testing are not Reliability, Security, Robustness are
performed in-depth Alpha Testing checked during Beta Testing

Alpha testing involves both the white Beta Testing typically uses black box
box and black box techniques testing

Alpha testing requires lab environment Beta testing doesn't require any lab
or testing environment environment or testing environment.
Software is made available to the public
and is said to be real time environment
Long execution cycle may be required for Only few weeks of execution are required
Alpha testing for Beta testing

Critical issues or fixes can be addressed by Most of the issues or feedback is collected
developers immediately in Alpha testing from Beta testing will be implemented in
future versions of the product

Alpha testing is to ensure the quality of Beta testing also concentrates on quality
the product before moving to Beta testing of the product, but gathers users input on
the product and ensures that the product
is ready for real time users.
Smoke Testing

• Smoke Testing is performed after software build to as certain


that the critical functionalities of the program is working
fine.
• It is executed "before" any detailed functional or regression
tests are executed on the software build. The purpose is to
reject a badly broken application, so that the QA team does
not waste time installing and testing the software application.
• In Smoke Testing, the test cases chosen cover the most
important functionality or component of the system. The
objective is not to perform exhaustive testing, but to verify
that the critical functionalities of the system is working fine.
For Example a typical smoke test would be - Verify that the
application launches successfully, Check that the GUI is
what is Sanity Testing?

After receiving a software build, with minor changes in code, or


functionality, Sanity testing is performed to ascertain that the
bugs have been fixed and no further issues are introduced due to
these changes. The goal is to determine that the proposed
functionality works roughly as expected. If sanity test fails, the
build is rejected to save the time and costs involved in a more
rigorous testing.

The objective is "not" to verify thoroughly the new functionality,


but to determine that the developer has applied some rationality
(sanity) while producing the software. For instance, if your
scientific calculator gives the result of 2 + 2 =5! Then, there is no
point testing the advanced functionalities like sin 30 + cos 50.
• Projects are broadly divided into two types of:
• 2 tier applications
• 3 tier applications
• CLIENT / SERVER TESTING
This type of testing usually done for 2 tier applications (usually developed for LAN)
Here we will be having front-end and backend.
• The application launched on front-end will be having forms and reports which will
be monitoring and manipulating data
• E.g: applications developed in VB, VC++, Core Java, C, C++, D2K, PowerBuilder etc.,
The backend for these applications would be MS Access, SQL Server, Oracle,
Sybase, Mysql, Quadbase
• The tests performed on these types of applications would be
– User interface testing
– Manual support testing
– Functionality testing
– Compatibility testing & configuration testing
– Intersystem testing
• WEB TESTING
• This is done for 3 tier applications (developed for Internet / intranet / xtranet)
Here we will be having Browser, web server and DB server.
• The applications accessible in browser would be developed in HTML, DHTML, XML,
JavaScript etc. (We can monitor through these applications)
• Applications for the web server would be developed in Java, ASP, JSP, VBScript, JavaScript,
Perl, Cold Fusion, PHP etc. (All the manipulations are done on the web server with the
help of these programs developed)
• The DBserver would be having oracle, sql server, sybase, mysql etc. (All data is stored in
the database available on the DB server)
• The tests performed on these types of applications would be
– User interface testing
– Functionality testing
– Security testing
– Browser compatibility testing
– Load / stress testing
– Interoperability testing/intersystem testing
– Storage and data volume testing
• A web-application is a three-tier application.
This has a browser (monitors data) [monitoring is done using html, dhtml, xml, javascript]-
> webserver (manipulates data) [manipulations are done using programming languages or
scripts like adv java, asp, jsp, vbscript, javascript, perl, coldfusion, php] -> database server
(stores data) [data storage and retrieval is done using databases like oracle, sql server,
sybase, mysql].
• The types of tests, which can be applied on this type of applications, are:
1. User interface testing for validation & user friendliness
2. Functionality testing to validate behaviors, i/p, error handling, o/p, manipulations,
services levels, order of functionality, links, content of web page & backend coverage’s
3. Security testing
4. Browser compatibility
5. Load / stress testing
6. Interoperability testing
7. Storage & data volume testing
• A client-server application is a two tier application.
This has forms & reporting at front-end (monitoring & manipulations are done) [using vb,
vc++, core java, c, c++, d2k, power builder etc.,] -> database server at the backend [data
storage & retrieval) [using ms access, sql server, oracle, sybase, mysql, quadbase etc.,]
• The tests performed on these applications would be
1. User interface testing
2. Manual support testing
3. Functionality testing
4. Compatibility testing
5. Intersystem testing
Some more points to clear the difference between client server, web and desktop
applications:
• Desktop application:
1. Application runs in single memory (Front end and Back end in one place)
2. Single user only
Client- Server Testing

a client, a server, and network

st
ue
q
Re
Client
Server
Network
Re
su
lt
Client machine
Server machine
Client-Server Testing
• Client-server software requires specific forms of
testing to prevent or predict fatal errors. Servers
go down, records lock, I/O (Input/Output)
errors and lost messages can really cut into the
benefits of adopting this network technology.
• Testing addresses system performance and
scalability by understanding how systems
respond to increased workloads and what
causes them to fail.
Types of architecture in client –Server computing

• 1-tier architecture.

• 2-tier architecture.

• 3-tier architecture.
1-tier architecture.
• In this category of client-server setting, the user
interface, marketing logic and data logic are present
in the same system.
2-tier architecture.
• A two-tier architecture is a software architecture in which a
presentation layer or interface runs on a client, and a data layer
or data structure gets stored on a server. Separating
these two components into different locations represents
a two-tier architecture, as opposed to a single-tier
architecture.
3-tier architecture.
–A three-tier architecture is a client-
server architecture in which the functional
process logic, data access, computer data storage
and user interface are developed and maintained
as independent modules on separate platforms.
Client Side testing
• GUI Testing
– Cross-Platform nature
– Event-driven nature
Server side Testing.
• Volume testing
• Stress testing
• Performance testing
• Data testing
• Security testing

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy