Scribd
Upload
11 views7 pages

SE Unit Iv Part 3

Uploaded by

cmptup2020
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
11 views7 pages

SE Unit Iv Part 3

Uploaded by

cmptup2020
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/ 7

UNIT-IV

Unit IV Software Testing


Software Testing: A Strategic Approach to Software Testing - Strategic Issues Test Strategies for
Conventional Software - Validation Testing - System Testing.Testing Conventional Applications: White-
Box Testing - Basis Path Testing - Control Structure Testing - Black-Box Testing.Testing Web
Applications: Testing Concepts for WebApps - The Testing Process - Content Testing - User Interface
Testing- Component-Level Testing - Configuration Testing -Security Testing - Performance Testing.

Unit V Test Automation and Software Maintenance Software Testing Plan and Test Case Preparation:
Introduction - Test Plan - Test Case. Test Automation: Expectations from Test Automation - Limitations -
Automation Strategy -Automation Frameworks Automation Metrics. Software Maintenance:
Introduction - Maintenance Activities - Maintenance Process -Maintenance Cost - Maintenance
Strategies.
.

By
Dr.C.Mohanapriya
MSc(CT).,Mphil.,SET.,PhD., 1
Performance testing

• It highlights common frustrations like slow loading times, server-busy errors,


and inconsistent response times, all of which are performance-related issues.
• Performance testing identifies problems caused by server limitations, network
bandwidth, database or operating system weaknesses, poorly designed WebApp
functionality, and other hardware or software deficiencies.
• The goals of performance testing are to
– (1) understand how the system handles increasing loads and
– (2) gather metrics to guide design improvements that enhance performance.

2
Performance Testing Objectives
Performance tests are designed to simulate real-world loading situations.
As the number of simultaneous WebApp users grows, or the number of online transactions
increases, or the amount of data (downloaded or uploaded) increases,
Performance testing will help answer the following questions:

• Does the server response time degrade to a point where it is noticeable and unacceptable?
• At what point (in terms of users, transactions, or data loading) does performance become
unacceptable?
• What system components are responsible for performance degradation?
• What is the average response time for users under a variety of loading conditions?
• Does performance degradation have an impact on system security?
• Is WebApp reliability or accuracy affected as the load on the system grows?
• What happens when loads that are greater than maximum server capacity are applied?
• Does performance degradation have an impact on company revenues?

3
To develop answers to these questions, two different performance tests are
conducted:
(1) load testing examines real-world loading at a variety of load levels and in a variety
of combinations, and
(2) stress testing forces loading to be increased to the breaking point to determine
how much capacity the WebApp environment can handle.

4
Load Testing
The intent of load testing is to determine how the WebApp and its server-side
environment will respond to various loading conditions.
N, number of concurrent users
T, number of online transactions per unit of time
D, data load processed by the server per transaction
• average user response, average time to download a standardized unit of data, or average
time to process a transaction.
• Load testing can also be used to assess recommended connection speeds for users of the
WebApp.
• Overall throughput, P, is computed in the following manner:
• P=Nx Tx D

5
Load Testing
• As an example, consider a popular sports news site. At a given moment, 20,000
concurrent users submit a request (a transaction, T) once every 2 minutes on
average.
• N (number of concurrent users) = 20,000
• T (transactions per unit of time) = 1 request every 2 minutes = 0.5 transactions
per minute
• D (data load per transaction) = 3 KB per article
• The throughput, P, is calculated as:
• P=N×T×D
P = 20,000 × 0.5 × 3 KB = 30,000 KB per minute
Dividing by 60 seconds gives:
P = 500 KB/sec = 4 megabits per second (Mbps)

6
Stress testing
• Stress testing builds on load testing by pushing the WebApp beyond its operational
limits to assess its behavior under extreme conditions.
• It aims to answer critical questions:-
– Does the system degrade gracefully, or does it crash when capacity is exceeded?-
– Do users receive "server not available" messages, and are they aware of server unavailability?-
– Does the server queue requests and process them once demand decreases?-
– Are transactions or data lost when capacity is exceeded?- How do N (users), T (transactions), and
D (data load) impact server failure, and are automated alerts sent to support staff?-
– If the system fails, how long does it take to recover?- Are certain WebApp functions discontinued
as capacity approaches 80-90%?
– A variation, spike/bounce testing, involves quickly increasing load to capacity and then lowering
it to normal levels repeatedly.
– This assesses the server's ability to handle sudden surges in demand and efficiently release
resources when load decreases.

You might also like