| Term /
Concept |
Description |
| Capacitiy |
The
capacity of a system is the total workload it can handle without violating
predetermined key performance acceptance criteria. |
| Capacity Test |
A
capacity test complements load testing by determining your server’s ultimate
failure point, whereas load testing monitors results at various levels of
load and traffic patterns. You perform capacity testing in conjunction with
capacity planning, which you use to plan for future growth, such as an
increased user base or increased volume of data. For example, to accommodate
future loads, you need to know how many additional resources (such as
processor capacity, memory usage, disk capacity, or network bandwidth) are
necessary to support future usage levels. Capacity testing helps you to
identify a scaling strategy in order to determine whether you should scale up
or scale out. |
| Component Test |
A
component test is any performance test that targets an architectural
component of the application. Commonly tested components include servers,
databases, networks, firewalls, and storage devices. |
| Endurance Test |
An
endurance test is a type of performance test focused on determining or
validating performance characteristics of the product under test when
subjected to workload models and load volumes anticipated during production
operations over an extended period of time. Endurance testing is a subset of
load testing. |
| Investigation |
Investigation
is an activity based on collecting information related to the speed,
scalability, and/or stability characteristics of the product under test that
may have value in determining or improving product quality. Investigation is
frequently employed to prove or disprove hypotheses regarding the root cause
of one or more observed performance issues. |
| Latency |
Latency
is a measure of responsiveness that represents the time it takes to complete
the execution of a request. Latency may also represent the sum of several
latencies or subtasks. |
| Metrics |
Metrics
are measurements obtained by running performance tests as expressed on a
commonly understood scale. Some metrics commonly obtained through performance
tests include processor utilization over time and memory usage by load. |
| Performance |
Performance
refers to information regarding your application’s response times,
throughput, and resource utilization levels. |
| Performance Test |
A
performance test is a technical investigation done to determine or validate
the speed, scalability, and/or stability characteristics of the product under
test. Performance testing is the superset containing all other subcategories
of performance testing described in this chapter. |
| Performance Budgets or Allocations |
Performance
budgets (or allocations) are constraints placed on developers regarding
allowable resource consumption for their component. |
| Performance Goals |
Performance
goals are the criteria that your team wants to meet before product release,
although these criteria may be negotiable under certain circumstances. For
example, if a response time goal of three seconds is set for a particular
transaction but the actual response time is 3.3 seconds, it is likely that
the stakeholders will choose to release the application and defer performance
tuning of that transaction for a future release. |
| Performance Objectives |
Performance
objectives are usually specified in terms of response times, throughput
(transactions per second), and resource-utilization levels and typically
focus on metrics that can be directly related to user satisfaction. |
| Performance Requirements |
Performance
requirements are those criteria that are absolutely non-negotiable due to
contractual obligations, service level agreements (SLAs), or fixed business
needs. Any performance criterion that will not unquestionably lead to a
decision to delay a release until the criterion passes is not absolutely
required ? and therefore, not a requirement. |
| Performance Targets |
Performance
targets are the desired values for the metrics identified for your project
under a particular set of conditions, usually specified in terms of response
time, throughput, and resource-utilization levels. Resource-utilization
levels include the amount of processor capacity, memory, disk I/O, and
network I/O that your application consumes. Performance targets typically
equate to project goals. |
| Performance Testing Objectives |
Performance
testing objectives refer to data collected through the performance-testing
process that is anticipated to have value in determining or improving product
quality. However, these objectives are not necessarily quantitative or
directly related to a performance requirement, goal, or stated quality of
service (QoS) specification. |
| Performance Thresholds |
Performance
thresholds are the maximum acceptable values for the metrics identified for
your project, usually specified in terms of response time, throughput
(transactions per second), and resource-utilization levels.
Resource-utilization levels include the amount of processor capacity, memory,
disk I/O, and network I/O that your application consumes. Performance
thresholds typically equate to requirements. |
| Resource Utilization |
Resource
utilization is the cost of the project in terms of system resources. The
primary resources are processor, memory, disk I/O, and network I/O. |
| Response Time |
Response
time is a measure of how responsive an application or subsystem is to a
client request. |
| Saturation |
Saturation
refers to the point at which a resource has reached full utilization. |
| Scalability |
Scalability
refers to an application’s ability to handle additional workload, without
adversely affecting performance, by adding resources such as processor,
memory, and storage capacity. |
| Scenarios |
In
the context of performance testing, a scenario is a sequence of steps in your
application. A scenario can represent a use case or a business function such
as searching a product catalog, adding an item to a shopping cart, or placing
an order. |
| Smoke Test |
A
smoke test is the initial run of a performance test to see if your
application can perform its operations under a normal load. |
| Spike Test |
A
spike test is a type of performance test focused on determining or validating
performance characteristics of the product under test when subjected to
workload models and load volumes that repeatedly increase beyond anticipated
production operations for short periods of time. Spike testing is a subset of
stress testing. |
| Stability |
In
the context of performance testing, stability refers to the overall
reliability, robustness, functional and data integrity, availability, and/or
consistency of responsiveness for your system under a variety conditions. |
| Stress Test |
A
stress test is a type of performance test designed to evaluate an
application’s behavior when it is pushed beyond normal or peak load
conditions. The goal of stress testing is to reveal application bugs that
surface only under high load conditions. These bugs can include such things
as synchronization issues, race conditions, and memory leaks. Stress testing
enables you to identify your application’s weak points, and shows how the
application behaves under extreme load conditions. |
| Throughput |
Throughput
is the number of units of work that can be handled per unit of time; for
instance, requests per second, calls per day, hits per second, reports per
year, etc. |
| Unit Test |
In
the context of performance testing, a unit test is any test that targets a
module of code where that module is any logical subset of the entire existing
code base of the application, with a focus on performance characteristics.
Commonly tested modules include functions, procedures, routines, objects,
methods, and classes. Performance unit tests are frequently created and
conducted by the developer who wrote the module of code being tested. |
| Utilization |
In
the context of performance testing, utilization is the percentage of time
that a resource is busy servicing user requests. The remaining percentage of
time is considered idle time. |
| Validation Test |
A
validation test compares the speed, scalability, and/or stability
characteristics of the product under test against the expectations that have
been set or presumed for that product. |
| Workload |
Workload
is the stimulus applied to a system, application, or component to simulate a
usage pattern, in regard to concurrency and/or data inputs. The workload
includes the total number of users, concurrent active users, data volumes,
and transaction volumes, along with the transaction mix. For performance
modeling, you associate a workload with an individual scenario. |
| Click |
A
simulated mouse click of a user sending a request (one of the URLs from the
URL list) to the server and immediately requesting any necessary redirects,
frames and images (if enabled). |
| Request |
An
HTTP request sent to the server regardless of an answer. |
| Hit |
A
completed HTTP request (i.e. sent to the server and answered completely).
Hits can be the PAGE request of a "click" or its frames, images
etc. |
| Time for DNS |
Time
to resolve a URL's domain name using the client system's current DNS server. |
| Time to connect |
Time
to set up a connection to the server. |
| Time to first byte (TFB) |
Time
between initiating a request and receiving the first byte of data from the
server. |
| Click Time |
The
time a user had to wait until his "click" was finished (including
redirections/frames/images etc.). |
| Click Delay |
The
time a user needs to view the webpage he just downloaded until he initiates
the next click |
| User Bandwidth |
The
bandwidth a user was able to achieve |
| Sent Requests |
Number
of requests sent to the server during a period. |
| Received Requests |
Number
of answers received from the server during a period. |
| Click Time |
A
simulated user’s mouse click that sends a request (one of the URLs from the
URL list) to the server and immediately requesting any necessary redirects,
frames and images (if enabled). The click time is calculated as the time
between when the user clicked and when the server delivered the requested
resources with all referenced items (images etc.). |
| Average Click Times |
The
average values per URL, per user or per website |
| Time for DNS |
Time
to resolve a URL's domain name using the client system's current DNS server. |
| Time to connect |
Time
to set up a connection to the server. |
| Time to first byte (TFB) |
Time
between initiating a request and receiving the first byte of data from the
server |
| Request Time (TLB, Time to last Byte) |
Time
for a single HTTP request (i.e. HTML page, image, frameset etc.) |
| User/Server Bandwidth |
The bandwidth a user and a server were able to achieve. |
| Sent Requests: |
Number of requests sent to the server during
a period. |
| Received Requests |
Number of answers received from the server
during a period. |
| Open Requests |
Number
of open request for a given moment |
| Error rates |
Number of failed request per time period,
per user or per URL |
![[src6.jpg]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiRg0S5m6Kv4Z7ccmmETli_3vWz6pC3y6fHMQkuWvCSikyn_bxIgrgAOSdj-gKaJu0DaNDuxqdxKTpSDf_8YBfJuowu4TAa6HJ3ZN8pOcnA4coqiv10UghITQ-ewJqQ99XoHOd42oAKnWT/s1600/src6.jpg)
