3. ●In performance testing, tester needs to check product’s speed, scalability and
stability
●Speed : Need to verify that application response is getting quick or not.
●Scalability : Need to verify that application can handle maximum user load.
●Stability : Need to verify that application is stable under varying load.
Performance Testing
Test Case # Test Case Domain
1 Application load time should not be more than 5 secs up to 1000
users accessing it simultaneously
Performance Testing
2 Software should be installable on all versions of Windows and Mac Compatibility Testing
3 All web images should have alt tags Accessibility testing.
4. ●Load testing - checks the application's ability to perform under anticipated user
loads. The objective is to identify performance bottlenecks before the software
application goes live.
●Stress testing - involves testing an application under extreme workloads to see
how it handles high traffic or data processing. The objective is to identify the
breaking point of an application.
●Volume testing - Under Volume Testing large no. of. Data is populated in a
database and the overall software system's behavior is monitored. The objective is
to check software application's performance under varying database volumes.
Performance Testing
5. Performance Testing Metrics: Parameters Monitored
● Bandwidth - shows the bits per second used by a network interface.
● Memory pages/second - number of pages written to or read from the disk in order to resolve hard
page faults. Hard page faults are when code not from the current working set is called up from
elsewhere and retrieved from a disk.
● Network bytes total per second - rate which bytes are sent and received on the interface
● Response time - time from when a user enters a request until the first character of the response is
received.
● Throughput - rate a computer or network receives requests per second.
Performance Testing
7. ●Security testing is a testing technique to determine if an information system
protects data and maintains functionality as intended.
●Security testing always involve with the SDLC cycle.
Security Testing
Requirement
- Security Analysis
Design
- Security Test plan
Coding/Unit Testing
- Security Whitebox
and Blackbox Testing
Implementation and
System testing
- Penetration
Vulnerability scanning
Release & Support
- Impact Analysis
8. Example Test Scenarios for Security Testing
● A password should be in encrypted format
● Application or System should not allow invalid users
● Check cookies and session time for application
● This is an example of a very basic security test which anyone can perform on a web site/application:
● Log into the web application.
● Log out of the web application.
● Click the BACK button of the browser (Check if you are asked to log in again or if you are provided the logged-in
application.)
● Most types of security testing involve complex steps and out-of-the-box thinking but, sometimes, it is
simple tests like the one above that help expose the most severe security risks.
Security Testing
9. Few security checkup points to check within Web Application
● Test the Role and Privilege Manipulation to Access the Resources.
● Test for cookie and parameter Tempering using web spider tools.
● Test for HTTP Request Tempering and check whether to gain illegal access to reserved
resources.
● Perform Code injection testing to identify input validation Error.
● Send Any Large number of Requests that perform database operations and observe any
Slowdown and New Error Messages
● Perform manual source code analysis and submit a range of input varying lengths to the
applications
Security Testing
10. Differences – Smoke vs. Sanity
Build 1
Build 2
Build 3
Build 21
Build 22
Build 23
.
.
.
Initial Build when
it is Unstable
Relatively stable
build after many
rounds of regression
Smoke Testing
Sanity Testing
Verify top approach critical
functionality
Verify new functionality and
Bug fixing
Test
Pass?
System or
Regression
Testing
Yes
11. Differences – Smoke vs. Sanity
Smoke Testing Sanity Testing
Smoke Test is done to make sure if the build we received
from the development team is testable or not
Sanity Test is done during the release phase to check for
the main functionalities of the application without going
deeper
Smoke Testing is performed by both Developers and
Testers
Sanity Testing is performed by Testers alone
Smoke Testing exercises the entire application from end to
end
Sanity Testing exercises only the particular component of
the entire application
Smoke Testing, build may be either stable or unstable Sanity Testing, build is relatively stable
Smoke testing is designed to include every part of the
application in a not thorough or detailed way.
Sanity testing is used to ensure that after a minor change a
small part of the application is still working.
The test cases for smoke testing of the software can be
either manual or automated
Sanity test is generally without test scripts or test cases.
12. Differences – Regression vs. Re-testing
Regression Testing Re-Testing
In Regression testing, you can include the test cases which
passed earlier. We can say that check the functionality
which was working earlier.
In Retesting, you can include the test cases which failed
earlier. We can say that check the functionality which was
failed in earlier build.
Regression testing can done by Automation testing Retesting cant be done by Automation testcases
Defect verification is not the part of Regression Testing Defect verification is the part of re-testing
Regression testing checks for unexpected side-effects Re-testing makes sure that the original fault has been
corrected
Regression testing is only done when there is any
modification or changes become mandatory in an existing
project
Re-testing executes a defect with the same data and the
same environment with different inputs with a new build