Pure Test - Software Testing

Tutorial
The best tester isn’t the one who finds the most bugs or who
embarrasses the most programmers. The best tester is the one who
gets the most bugs fixed.
1. Performance Testing
In white box testing testers, developers, system administrators and DBAs
work together in order to instrument the application code and the
database queries (via specialized profilers for example), and the
hardware/operating system of the server(s) running the application and
the database (via monitoring tools such as vmstat, iostat, top or Windows
PerfMon). All these activities belong to performance testing.

The goal of performance testing is not to find bugs, but to eliminate

bottlenecks and establish a baseline for future regression testing.

These bottlenecks can exist at multiple levels:

a. at the application level, developers can use profilers to spot
inefficiencies in their code (for example poor search algorithms)

b. at the database level, developers and DBAs can use database-specific

profilers and query optimizers

c. at the operating system level, system engineers can use utilities such
as top, vmstat, iostat (on Unix-type systems) and PerfMon (on Windows)
to monitor hardware resources such as CPU, memory, swap, disk I/O;
specialized kernel monitoring software can also be used

d. at the network level, network engineers can use packet sniffers such as
tcpdump, network protocol analyzers such as ethereal, and various
utilities such as netstat, MRTG, ntop, mii-tool.

From a testing point of view, the activities described above all take a
white-box approach, where the system is inspected and monitored "from
the inside out" and from a variety of angles.

2. Load Testing
Are you actively profiling your application code and/or monitoring the
server(s) running your application? If the answer is yes, then you're
engaged in performance testing. If the answer is no, then what you're
doing is load testing.

In the testing literature, the term "load testing" is usually defined as the
process of exercising the system under test by feeding it the largest tasks
it can operate with. Load testing is sometimes called volume testing, or
longevity/endurance testing.

Examples of volume testing

a. testing a word processor by editing a very large document

b. testing a printer by sending it a very large job

c. testing a mail server with thousands of users mailboxes

d. a specific case of volume testing is zero-volume testing, where the

system is fed empty tasks

Examples of longevity/endurance testing

a. testing a client-server application by running the client in a loop
against the server over an extended period of time

Goals of load testing

a. expose bugs that do not surface in cursory testing, such as memory
management bugs, memory leaks, buffer overflows, etc.

b. ensure that the application meets the performance baseline established

during performance testing. This is done by running regression tests
against the application at a specified maximum load.

Although performance testing and load testing can seem similar, their
goals are different. On one hand, performance testing uses load testing
techniques and tools for measurement and benchmarking purposes and
uses various load levels. On the other hand, load testing operates at a
predefined load level, usually the highest load that the system can accept
while still functioning properly. Note that load testing does not aim to
break the system by overwhelming it, but instead tries to keep the
system constantly humming like a well-oiled machine.

3. Stress Testing

If you want to actually discover bugs and to see if your application fails
and recovers gracefully, you need to do stress testing. Blast your Web
server with double the number of users for example. Unplug network
cables randomly (or shut down/restart switch ports via SNMP). Take out a
disk from a RAID array.
The main purpose behind this madness is to make sure that the system
fails and recovers gracefully.

Here are some ways in which stress can be applied to the system:
a. double the baseline number for concurrent users/HTTP connections
b. randomly shut down and restart ports on the network switches/routers
that connect the servers (via SNMP commands for example)

c. take the database offline, then restart it

d. rebuild a RAID array while the system is running

e. run processes that consume resources (CPU, memory, disk, network)

on the web and database servers
If chair is designed for 100 kg weight, and my weight is 70 kg then that
testing is called as normal testing. If my weight is 100 kg then that
testing is called as load testing. If my wt is 120 kg then that testing
called as stress testing.

Differences

a. Performance test: To determine or validate speed, scalability, and/or

stability.

b. Load test: To verify application behavior under normal and peak load
conditions

c. Stress test: To determine or validate an application’s behavior when it

is pushed beyond normal or peak load conditions.

d. Capacity test: To determine how many users and/or transactions a

given system will support and still meet performance goals.

Related Testing Topic

a. Black Box testing

1 Comments:

vik said...
good article with simple examples. Thanks.

May 14, 2010 7:39:00 AM PDT

Post a Comment

Links to this post

Create a Link

Newer Post Older Post Home

Subscribe to: Post Comments (Atom)

More on Software Testing

 Agile Testing
 Black Box testing
 RTM, Static & Dynamic Testing
 Web Testing Checklist
 Desktop App Testing Checklist
 Testing for Beginners
 Testing Concepts
 Smartphone Testing
 Error, Bug & Defect
 Testing Models
 Testing Techniques
 Load testing
 Usability Testing
 Localization Testing
 GUI Testing
 QA, QC & Testing
 Negative Testing
 Severity vs Priority
 Creativity of Testers
 Testing Quotes
 Selenium Tutorial
 Having Other People Test....
 Realities of QA
 Testing Experiences
 POWERCFG -Energy
 Test Cases
 Testing Tools

With Love
 Intelligaia
 Chaos to Clarity
 List of Universities
 ISTQB EXAM QUESTIONS