01 handout performancetesting v1 1 .0

7/29/2019 01 Handout PerformanceTesting v1 1 .0

1/31

Handout:

Performance TestingVersion: ST/Handout/0907/1.0

Date: 28-09-07

Cognizant

500 Glen Pointe Center West

Teaneck, NJ 07666

Ph: 201-801-0233

www.cognizant.com


2/31

Handout - Performance Testing

Page 2Copyright 2007, Cognizant Technology Solutions, All Rights Reserved

C3: Protected

TABLE OF CONTENTS

Introduction ................................................................................................................................4About this Module ......................................................................................................................4Target Audience.........................................................................................................................4Module Objectives .....................................................................................................................4Pre-requisite ..............................................................................................................................4

Chapter 1: Introduction to Performance Testing.......................................................................5Learning Objectives ...................................................................................................................5What is Performance Testing?...................................................................................................5Why Performance Testing..........................................................................................................5Performance Testing Objectives ................................................................................................6

Pre-requisites for a Performance Test .......................................................................................6Summary ...................................................................................................................................7Test Your Understanding ...........................................................................................................7

Chapter 2: Performance Testing Requirements........................................................................8Learning Objectives ...................................................................................................................8Performance Testing Requirements...........................................................................................8Summary .................................................................................................................................10Test your Understanding..........................................................................................................10

Chapter 3: Performance Testing Process................................................................................11Learning Objectives .................................................................................................................11Performance Testing Process..................................................................................................11Summary .................................................................................................................................15Test your Understanding..........................................................................................................15

Chapter 4: Performance Testing Tools ....................................................................................17Learning Objectives .................................................................................................................17What are the tools for Performance testing?............................................................................17Summary .................................................................................................................................24Test your Understanding..........................................................................................................24

Chapter 5: Load, Volume and Stress testing ...........................................................................25Learning Objectives .................................................................................................................25Load Testing ............................................................................................................................25


3/31



C3: Protected

Volume and Stress Testing......................................................................................................25Summary .................................................................................................................................27Test your Understanding..........................................................................................................28

Glossary .....................................................................................................................................29References .................................................................................................................................30

Websites..................................................................................................................................30Books.......................................................................................................................................30

STUDENT NOTES: .....................................................................................................................31


4/31



C3: Protected

Introduction

About this Module

This module provides you with a brief description of the module, audience, suggestedprerequisites and module objectives.

Target Audience

Entry Level Trainees

Module Objectives

After completing this module, the student will be able to:

Understand basic concepts of Performance Testing

Understand Performance Testing Requirements

Understand Performance Testing Process Understand Performance Testing tools

Pre-requisite

Students should have the knowledge of manual testing


5/31



C3: Protected

Chapter 1: Introduction to Performance Testing

Learning Objectives

After completing this chapter, you will be able to:

Understand the concept of Performance testing

Understand how to test the performance of a software

What is Performance Testing?

The performance testing is a measure of the performance characteristics of an application. The

main objective of a performance testing is to demonstrate that the system functions to specification

with acceptable response times while processing the required transaction volumes in real-time

production database

The objective of a performance test is to demonstrate that the system meets requirements fortransaction throughput and response times simultaneously. The main deliverables from such a

test, prior to execution, are automated test scripts and an infrastructure to be used to execute

automated tests for extended periods.

Performance testing of an application is basically the process of understanding how the web

application and its operating environment respond at various user load levels. In general, we want

to measure the latency, throughput, and utilization of the web site while simulating attempts by

virtual users to simultaneously access the site. One of the main objectives of performance testing

is to maintain a web site with low latency, high throughput, and low utilization.

Why Performance Testing

Performance problems are usually the result of contention for, or exhaustion of, some system

resource. When a system resource is exhausted, the system is unable to scale to higher levels of

performance. Maintaining optimum Web application performance is a top priority for application

developers and administrators.

Performance analysis is also carried for various purposes such as:

During a design or redesign of a module or a part of the system, more than one

alternative presents itself. In such cases, the evaluation of a design alternative is the

prime mover for an analysis.

Post-deployment realities create a need for the tuning the existing system. A

systematic approach like performance analysis is essential to extract maximum benefit

from an existing system.

Identification of bottlenecks in a system is more of an effort at troubleshooting. This

helps to replace and focus efforts at improving overall system response. As the user

base grows, the cost of failure becomes increasingly unbearable.

To increase confidence and to provide an advance warning of potential problems In

case of load conditions, analysis must be done to forecast performance under load.


6/31



C3: Protected

Example:

Typically to debug applications, developers would execute their applications using different

execution streams (i.e., completely exercise the application) in an attempt to find errors. When

looking for errors in the application, performance is a secondary issue to features; However, it is

still an issue.

Performance Testing Objectives

The objective of a performance test is to demonstrate that the system meets requirements for

transaction throughput and response times simultaneously. This infrastructure is an asset and an

expensive one too, so it pays to make as much use of this infrastructure as possible.

Fortunately, this infrastructure is a test bed, which can be re-used for other tests with broader

Objectives.

The performance testing goals are:

End-to-end transaction response time measurements.

Measure Application Server components performance under various loads.

Measure database components performance under various loads.

Monitor system resources under various loads.

Measure the network delay between the server and clients

Pre-requisites for a Performance Test

We can identify pre-requisites for a performance test. Not all of these need be in place prior to

planning or preparing the test (although this might be helpful), but rather, the list defines what is

required before a test can be executed.First and foremost thing is, the design specification or a

separate performance requirements document should:

Defines specific performance goals for each feature that is instrumented.

Bases performance goals on customer requirements.

Defines specific customer scenarios.

Quantitative, relevant, measurable, realistic, achievable requirements:

As a foundation to all tests, performance requirements should be agreed prior to the test. This

helps in determining whether or not the system meets the stated requirements. The following

attributes will help to have a meaningful performance comparison.

Quantitative - expressed in quantifiable terms such that when response times are

measured, a sensible comparison can be derived.

Relevant - a response time must be relevant to a business process.

Measurable - a response time should be defined such that it can be measured using a

tool or stopwatch and at reasonable cost.

Realistic - response time requirements should be justifiable when compared with thedurations of the activities within the business process the system supports.

Achievable - response times should take some account of the cost of achieving them.

Stable system

A test team attempting to construct a performance test of a system whose software is of poor

quality is unlikely to be successful. If the software crashes regularly, it will probably not withstand


7/31



C3: Protected

the relatively minor stress of repeated use. Testers will not be able to record scripts in the first

instance, or may not be able to execute a test for a reasonable length of time before the software,

middleware or operating systems crash.

Realistic test environment

The test environment should ideally be the production environment or a close simulation and be

dedicated to the performance test team for the duration of the test. Often this is not possible.However, for the results of the test to be realistic, the test environment should be comparable to

the actual production environment. A test environment which bears no similarity to the actual

production environment may be useful for finding obscure errors in the code, but is, however,

useless for a performance test.

Summary

The performance testing is a measure of the performance characteristics of an

application

The objective of a performance test is to demonstrate that the system meets

requirements for transaction throughput and response times simultaneously.

Performance analysis is also carried during design, post-deployment, to identify thebottle-necks in the system and to provide an advance warning of potential problems

Pre-requisites for Performance Testing are Quantitative, relevant, measurable,

realistic, achievable requirements, Stable System and Realistic test environment

Test Your Understanding

1. The testing to measure the performance characteristics of an application is

a) Unit testing

b) Integration testing

c) System testing

d) Performance testing

e) Acceptance testing

Ans: d


8/31



C3: Protected

Chapter 2: Performance Testing Requirements

Learning Objectives

After completing this chapter, you will be able to: Understand the requirements for performance testing

The process for Performance testing

Performance Testing Requirements

Performance requirements normally comprise three components:

Response time requirements

Transaction volumes detailed in Load Profiles

Database volumes

Response time requirementsWhen asked to specify performance requirements, users normally focus attention on response

times, and often wishes to define requirements in terms of generic response times. A single

response time requirement for all transactions might be simple to define from the users point of

view, but is unreasonable. Some functions are critical and require short response times, but others

are less critical and response time requirements can be less stringent.

Load profiles

The second component of performance requirements is a schedule of load profiles. A load profile

is the level of system loading expected to occur during a specific business scenario. Business

scenarios might cover different situations when the users organization has different levels of

activity or involve a varying mix of activities, which must be supported by the system.

Database volumes

Data volumes, defining the numbers of table rows which should be present in the database after a

specified period of live running complete the load profile. Typically, data volumes estimated to exist

after one years use of the systems are used, but two year volumes or greater might be used in

some circumstances, depending on the business application.

Architecture Benchmarking

Hardware Benchmarking

Hardware benchmarking is performed to size the application with the planned Hardware platform.It is significantly different from capacity planning exercise in that it is done after development and

before deployment

Software Benchmarking

Defining the right placement and composition of software instances can help in vertical scalability

of the system without addition of hardware resources. This is achieved through software

benchmark test.


9/31



C3: Protected

General Tests

What follows is a list of tests adaptable to assess the performance of most systems. The

methodologies below are generic, allowing one to use a wide range of tools to conduct the

assessments.

Methodology Definitions

Result: provide information about what the test will accomplish.

Purpose: explains the value and focus of the test, along with some simple background

information that might be helpful during testing.

Constraints: details any constraints and values that should not be exceeded during

testing.

Time estimate: a rough estimate of the amount of time that the test may take to

complete.

Type of workload: in order to properly achieve the goals of the test, each test requires

a certain type of workload. This methodology specification provides information on the

appropriate script of pages or transactions for the user.

Methodology: a list of suggested steps to take in order to assess the system undertest.

What to look for: contains information on behaviors, issues and errors to pay attention

to during and after the test.

Performance Metrics

The Common Metrics selected /used during the performance testing is as below

Response time

Turnaround time = the time between the submission of a batch job and the completion

of its output.

Stretch Factor: The ratio of the response time with single user to that of concurrent

users.

Throughput: Rate (requests per unit of time) Examples:

Jobs per second

Requests per second

Millions of Instructions Per Second (MIPS)

Millions of Floating Point Operations Per Second (MFLOPS)

Packets Per Second (PPS)

Bits per second (bps)

Transactions Per Second (TPS)

Capacity:

Nominal Capacity: Maximum achievable throughput under ideal workload conditions.

E.g., bandwidth in bits per second. The response time at maximum throughput is too high.

Usable capacity: Maximum throughput achievable without exceeding a prespecified

response-time limit

Efficiency: Ratio usable capacity to nominal capacity. Or, the ratio of the performance

of an processor system to that of a one-processor system is its efficiency.


10/31



C3: Protected

Utilization: The fraction of time the resource is busy servicing requests.

Average Fraction used for memory.

Client Side Statistics

Running Vusers

Hits per Second

Throughput HTTP Status Code

HTTP responses per Second

Pages downloaded per Second

Transaction response time

Page Component breakdown time

Page Download time

Component size Analysis

Error Statistics

Errors per Second

Total Successful/Failed Transactions Server Side Statistics

System Resources - Processor Utilization, Memory and Disk Space

Web Server ResourcesThreads, Cache Hit Ratio

Application Server ResourcesHeap size, JDBC Connection Pool

Database Server ResourcesWait Events, SQL Queries

Transaction Profiling

Code Block Analysis

Network Statistics

Bandwidth Utilization

Network delay time

Network Segment delay time

Summary

Performance requirements normally comprise three components:

Response time requirements

Transaction volumes detailed in Load Profiles

Database volumes

Test your Understanding

1. What are the requirements required for Performance testinga) Response time requirements

b) Transaction volumes detailed in Load Profiles

c) Database volumes

d) Al the above

Ans:d


11/31



C3: Protected

Chapter 3: Performance Testing Process

Learning Objectives


The process for Performance testing

Performance Testing Process

Phase 1 Requirements Study


12/31



C3: Protected

This activity is carried out during the business and technical requirements identification phase. The

objective is to understand the performance test requirements, Hardware & Software components

and Usage Model. It is important to understand as accurately and as objectively as possible the

nature of load that must be generated. Following are the important performance test requirement

that needs to be captured during this phase.

Response Time

Transactions Per Second

Hits Per Second

Workload

No of con current users

Volume of data

Data growth rate

Resource usage

Hardware and Software configurations

Phase 2 Test Plan

The following configuration information will be identified as part of performance testing

environment requirement identification.

Hardware Platform

Server Machines

Processors

Memory

Disk Storage

Load Machines configuration

Network configuration

Software Configuration

Operating System

Server Software

Client Machine Software

Applications


13/31



C3: Protected

Phase 3 Test Design

Based on the test strategy detailed test scenarios would be prepared. During the test design

period the following activities will be carried out:

Scenario design

Detailed test execution plan

Dedicated test environment setup

Script Recording/ Programming

Script Customization (Delay, Checkpoints, Synchronizations points)

Data Generation

Parameterization/ Data pooling

Phase 4 Scripting

Phase 5 Test Execution

The test execution will follow the various types of test as identified in the test plan. All the

scenarios identified will be executed. Virtual user loads are simulated based on the usage pattern

and load levels applied as stated in the performance test strategy.


14/31



C3: Protected

The following artifacts will be produced during test execution period:

Test logs

Test Result

Phase 6 Test Analysis

Phase 7 Preparation of Reports

The test logs and results generated are analyzed based on Performance under various load,

Transaction/second, database throughput, Network throughput, Think time, Network delay,

Resource usage, Transaction Distribution and Data handling. Manual and automated results

analysis methods can be used for performance results analysis.

The following performance test reports/ graphs can be generated as part of performance testing:-

Transaction Response time Transactions per Second

Transaction Summary graph

Transaction performance Summary graph

Transaction Response graph Under load graph

Virtual user Summary graph

Error Statistics graph

Hits per second graph

Throughput graph

Down load per second graph

Based on the Performance report analysis, suggestions on improvement or tuning will

be provided to the design team:

Performance improvements to application software, middleware, database

organization.

Changes to server system parameters.

Upgrades to client or server hardware, network capacity or routing.


15/31



C3: Protected

Common Mistakes in Performance Testing No Goals

No general purpose model

Goals =>Techniques, Metrics, Workload

Not trivial

Biased Goals

To show that OUR system is better than THEIRS

Analysts = Jury

Unsystematic Approach

Analysis without Understanding the Problem

Incorrect Performance Metrics Unrepresentative Workload

Wrong Evaluation Technique

Overlook Important Parameters

Ignore Significant Factors

Inappropriate Experimental Design

Inappropriate Level of Detail

Summary

Performance testing process involves seven phases as

o Phase 1 Requirements Studyo Phase 2 Test Plan

o Phase 3 Test Design

o Phase 4 Scripting

o Phase 5 Test Execution

o Phase 6 Test Analysis

o Phase 7 Preparation of Reports


1. The activities done during test design are

a) Scenario design

b) Detailed test execution plan

c) Transaction Response time

d) Dedicated test environment setup

I. only a

II. only a, b &d


16/31



C3: Protected

III. both a & b

IV. all the above

2. Arrange the different phases of testing process in order

a) Requirements Study

b) Test Plan

c) Test Design

d) Scripting

e) Test Execution

f) Test Analysis

g) Preparation of Reports

I. a, b, c, d, e, f &g

II. a, c, d, e, b, f &g

III. c, d, a ,e, b, g & f

Answers:1. II

2. I


17/31



C3: Protected

Chapter 4: Performance Testing Tools

Learning Objectives


Know the tools needed for performance testing

What are the tools for Performance testing?

Performance testing is to test software intended for a multi-user audience for the desired

performance by subjecting it with an equal amount of virtual users and then monitoring the

performance under the specified load, usually in a test environment identical to the production,

before going live.

Testing for most applications will be automated. Tools used for testing would be the tool specified

in the requirement specification. Various tools are also available to find out the causes for slowperformance which could be in the following areas:

Application

Database

Network

Client side processing

Load Balancer

For example if a web site with a shopping cart is intended for 100 concurrent users who are doing

the following functions:

25 VUsers are browsing through the items and logging off

25 Vusers are adding items to the shopping cart and checking out and logging off

25 VUsers are returning items previously purchased and logging off

25 VUsers are just logged in without any activity

Using various tools available to generate these VUsers the application is subjected to a 100 VUser

load as shown above and its performance is monitored

The tools used for performance testing are Loadrunner 6.5 and Webload 4.5x.

LoadRunner 6.5

LoadRunner is Mercury Interactives tool for testing the performance of client/server systems.

LoadRunner enables you to test your system under controlled and peak load conditions. To

generate load, LoadRunner runs thousands of Virtual Users that are distributed over a network.

Using a minimum of hardware resources, these Virtual users provide consistent. Repeatable and

measurable load to execute your client/server system just as real users would. Load Runners in

depth reports and graphs provide the information that you need to evaluate the performance of

your client/server system.


18/31



C3: Protected

WebLoad 4.5

Webload is a testing tool for testing the scalability, functionality and performance of Webbased

applications both Internet and Intranet. It can measure the performance of your application under

any load conditions. Use WebLoad to test how well your web site will perform under realworld

conditions by combining performance, load and functional tests or by running them individually.

Webload supports HTTP1.0 and 1.1, including cookies, proxies, SSL, TSL, client certificates,authentifications, persistent connections and chunked transfer coding. Webload generates load by

creating virtual clients that emulate network traffic. You create test scripts (called agendas) using

Java Scripts that instruct those virtual clients about what to do. When Webload runs the test, it

gathers results at a per-client, per-transaction and per-instance level from the computers that are

generating the load. Webload can also gather information servers performance monitor. You can

watch the results as they occur- Webload displays them in graphs and tables in real-time and you

can save and export the results when the test is finished.

Performance Testing Tools - summary and comparison


19/31



C3: Protected


20/31



C3: Protected


21/31



C3: Protected


22/31



C3: Protected


23/31



C3: Protected


24/31



C3: Protected

Summary

Performance testing is to test software intended for a multi-user audience for the

desired performance by subjecting it with an equal amount of virtual users and then

monitoring the performance under the specified load, usually in a test environment

identical to the production, before going live.

The tools used for performance testing are Loadrunner 6.5 and Webload 4.5x.


1. What are the tools needed for performance testing?

2. What is the tool for testing the performance of client/server systems?

3. What is the tool for testing the performance of Webbased Applications?

Answers:

1. Loadrunner 6.5 and Webload 4.5x.

2. Loadrunner 6.5

3. Webload 4.5x.


25/31



C3: Protected

Chapter 5: Load, Volume and Stress testing

Learning Objectives


Know the concepts of Load ,Volume and Stress testing

Load Testing

Load Testing is creation of a simulated load on a real computer system by using virtual users who

submit work as real users would do at real client workstations and thus testing the systems ability

to support such workload.

Testing of critical web applications during its development and before its deployment should

include functional testing to confirm to the specifications, performance testing to check if it offers

an acceptable response time and load testing to see what hardware or software configuration willbe required to provide acceptable response time and handle the load that will created by the real

users of the system

Load testing gives the greatest line of defense against poor performance and accommodates

complementary strategies for performance management and monitoring of a production

environment. The discipline helps businesses succeed in leveraging Web technologies to their

best advantage, enabling new business opportunity lowering transaction costs and strengthening

profitability.

Why is load testing important?

Load Testing increases the uptime for critical web applications by helping you spot the bottlenecks

in the system under large user stress scenarios before they happen in a production environment.

For example, a word processor or graphics editor can be forced to read an extremely large

document; or a financial package can be forced to generate a report based on several years' worth

of data. The most accurate load testing occurs with actual, rather than theoretical, results.

Volume and Stress Testing

Volume testing

Volume Testing, as its name implies, is testing that purposely subjects a system (both hardware

and software) to a series of tests where the volume of data being processed is the subject of the

test. Such systems can be transactions processing systems capturing real time sales or could be

database updates and or data retrieval.

Volume testing will seek to verify the physical and logical limits to a system's capacity and

ascertain whether such limits are acceptable to meet the projected capacity of the organization's

business processing. Volume Testing is conducted in conjunction with Component, Configuration

and/or Stress Testing.


26/31



C3: Protected

Stress testing is the system testing of an integrated, black box application that attempts to Cause

failures involving how its performance varies under extreme but valid conditions (e.g., extreme

utilization, insufficient memory inadequate hardware, and dependency on over utilized shared

resources).

Goals

The typical goals of stress testing are to:

Because the application to fail to scale gracefully under extreme conditions so that

the underlying defects can be identified, analyzed, fixed, and prevented in the future.

Objectives

The typical objectives of stress testing are to:

Partially validate the application (i.e., to determine if it fulfills its scalability

requirements).

Determine how an application degrades and eventually fails, as conditions become

extreme. For example, stress testing could involve an extreme number of

simultaneous users, extreme numbers of transactions, queries that return the entirecontents of a database, queries with an extreme number of restrictions, or an entry at

the maximum amount of data in a field.

Report these failures to the development teams so that the associated defects can be

fixed.

Determine if the application will support "worst case" production load conditions.

Provide data that will assist systems engineers in making intelligent decisions

regarding future scaling needs.

Help determine the extent to which the application is ready for launch.

Provide input to the defect trend analysis effort.

ExamplesTypical examples include stress testing of an application that is:

Software only.

A system including software, hardware, and data components.

Huge (e.g., number of users, number of transactions, amount of data).

Batch with no realtime requirements.

Soft realtime (i.e., human reaction times).

Hard realtime (e.g., avionics, radar, automotive engine control).

Embeded within another system (e.g., flight-control software, cruise-control software).

Client/server or n-tier distributed.

A research prototype that will not be placed into service. Business-critical or safety-critical.

Preconditions

Stress test execution can typically begin when the following preconditions hold:

The scalability requirements to be tested have been specified.

The relevant software components have passed unit testing.


27/31



C3: Protected

Software integration has occurred (i.e., load testing can begin prior to the distribution

of the software components onto the hardware components).

The relevant system components have passed system integration testing.

The independent test team is adequately staffed and trained in stress testing.

The test environment is ready.

Completion Criteria

Stress testing is typically complete when the following post conditions hold:

At least one stress test suite exists for each scalability requirement.

The test suites for every scheduled scalability requirement execute successfully.

Tasks

Stress testing typically involves the independent test team performing the following testing tasks

using the following techniques:

Test Planning

Test Reuse

Test Design:o Use Case Based Testing

o Workload analysis to determine the maximum production workloads.

Test Implementation:

o Develop test scripts

o Simulating extreme workloads.

Test Execution:

o Regression Testing

o Profiling

Test Reporting

Environments

Load testing is typically performed on the following environments using the following tools:

Test Environment:

o Test Harness

o Use case modeling tool

o Performance analyzer

o Profiler

Summary

A system can fulfill its operational requirements and still be a failure if it does not

scale.

The iterative and incremental development cycle implies that stress testing is regularly

performed in an iterative and incremental manner.

Stress testing must be automated if adequate regression testing is to occur.

Stress testing can elicit failures prior to launch.

Develop test scripts simulating exceptional workloads.


28/31



C3: Protected

Perform stress testing for several minutes to several hours.


Explain stress, volume and load testing?

Case Study

Assume word processor or graphics editor is forced to read an extremely large

document; or a financial package to generate a report based on several years' worth

of data.

Your assignment is to identify and analyze the issues and develop a test strategy for

the situation. This strategy should describe how you will predict whether the system's

performance is likely to be acceptable when it is placed in live operation


29/31



C3: Protected

Glossary

Term Definition

Stability Stability is the overall reliability, robustness, functional and data integrity,

availability, and/or consistency of responsiveness for your system under a

variety conditions

Scalability Scalability is the ability to handle additional workload without adversely

affecting performance, by adding resources such as CPU, memory, and

storage capacity

Capacity Capacity is the ability to handle workload at any given time within the key

performance requirements

Response time Response time is a measure of how responsive an application or subsystem

is to a client request.

Throughput Throughput is the measure of units of work performed in a given time period.

Utilization Percentage of time a resource is busy servicing user requests. The

remaining percentage of time is idle time.

Resource

utilization

Resource utilization is the measure of how many server and network

resources are consumed by your application. Resources include CPU,

memory, disk I/O, and network I/O. Resource utilization can be seen as the

cost in terms of system resources.

Saturation It is when a resource has reached full utilization

Workload It is the stimulus to system, application or component to simulate an usage

pattern, in regards to concurrency and/or data inputs.

Performance

Metrics

Metrics are the criteria you use to measure your system against the

performance objectives. These criteria can include CPU, memory, disk I/O,

network I/O, and resource utilization levels


30/31



C3: Protected

References

Websites

http://www.sqatester.com/

http://www.testing.com/

Cognizant eResources:

http://elibrary/

\\ctsintcosaca\library

Books

Automated Software Testing: Introduction, Management, and Performance, by Elfriede

Dustin, Jeff Rashka, John Paul & Paperback Practical Tools and Techniques for Managing Hardware and Software Testing, by,

Rex Black

50 Ways to improve your testing, by, Elfriede Dustin

Effective use of Test automation tools, by, Mark Fewster & Dorothy Graham

The craft of software testing, by, Brian Marick

Software test automation, by, Bret Pettichord


31/31


STUDENT NOTES:

01 handout performancetesting v1 1 .0

Documents