whitepaper: volume testing thick clients and databases

copyright Real-Time Technology Solutions, Inc. July 2015 page 1

Volume Testing

of

Thick Clients and Databases

using

Rational Performance Tester


Volume Testing Thick Clients and Databases

Using IBM Rational Performance Tester

Introduction Even in the current age of cloud computing there are still endless benefits of developing thick client

software: non-dependency on browser version, offline support, low hosting fees, and utilizing existing end

user hardware, to name a few.

It's more than likely that your organization is utilizing at least a few thick client applications. Now consider

this: as your user base grows, does your think client's backend server need to grow as well? How quickly?

How do you ensure that you provide the correct amount of additional capacity without overstepping and

unnecessarily eating into your profits? The answer is volume testing.

What is a thick client?

A thick client, sometimes also referred to as a fat client, is an application in which the bulk of its

functionality is performed independent of the end-server. Many thick client applications communicate

directly with the backend database directly rather than transmit their requests through a web server or

any other middle tier technology.

For example, a thick client may be an application used to manage the inventory on a retail website. A

transaction such as adding a new product may involve a wizard which collects the product information,

pricing, images, and shipping options while offline, then finally connecting to the backend database to

transmit this data.

What are the challenges of volume testing thick clients?

Traditionally, the tools designed for volume or performance testing are geared specifically to work only

with web-based applications. They record HTTP based traffic between the user's internet browser window

and the application’s web server. So what happens when there is neither an internet browser nor a web

server in play? Therein lies the challenge.

If an engineer can't capture the traffic being sent from the thick client front end to the database back end

then it will be impossible to automate the transactions.

Some engineers may attempt to do volume testing through the front end by automating the thick client

GUI itself. However, this approach will never be able to simulate the traffic necessary to meet the test

requirements. Think about the example above with the retail website: how long would it take you to enter

a product name, code, category, sub category, description, price, shipping options, available quantity, and

images? Even if you could click and type at 100 times human speed it would still take you at least a few

seconds. Now imagine that you need to enter 200 products per minute to fulfill your requirements. It

simply isn't possible using GUI automation.

So, how do we volume test a thick client application?


The RTTS solution

Through years of experience and knowledge with software quality and networking tools, RTTS has pieced

together a solution which bridges the gap between thick client applications and performance testing tools.

Our solution involves using a network monitor to manually capture all traffic moving between the front

end and the back end of your application. The capture is then carefully analyzed to filter out just the

pertinent parts of the conversation - SQL statements.

Using a custom tailored API, the captured SQL is then integrated with performance testing software which

allows us to simulate multiple concurrent users, verify application stability, and monitor back end systems

during execution.

Can this solution be used for database volume testing?

Absolutely. We can use the same approach to feed SQL queries into the performance testing software and

simulate concurrent user sessions on the database.

Pieces of the Puzzle Below are the three key components to thick client and database volume testing.

IBM Rational Performance Tester (RPT)

Software which allows for automated performance testing of web applications. It works by replaying

recorded application traffic through multiple threads to simulate concurrent users. RPT features a rich set

of capabilities for varying input data, controlling workflows, asserting transactional success, collecting

performance metrics, and monitoring backend servers.


Java Development Kit (JDK)

A collection of libraries used for development in the Java programming language. Java custom code is

utilized to extend the testing capabilities of RPT.

Wireshark

A network tracing tool capable of collecting and analyzing all traffic on a specified network interface.

Wireshark is capable of filtering individual streams of network communications based on specified servers

and timestamps.


Eyes On It's time to see exactly how we implement this solution using the software listed above.

Capture

The first step is to execute a transaction from within the thick client application and record the network

traffic using Wireshark. For this example we will use a simple production assistant application which is

capable of fetching show information based on user specified filters. We use the “Actors” tab to fetch all

actors who have last names containing the word “PARK”.


By applying filters to our Wireshark recording, we find the TCP stream which represents the

conversation between the application and the database.

Upon close analysis, we see that the client sent the following SQL statement to the database:

"select * from actor where last_name LIKE 'PARK%'"


Integration

The second step is to use the SQL data we collected to create a performance test script using IBM

Rational Performance Tester (RPT). We use RPT controls such as loops, transactions, and conditionals to

control the flow of the transactions; while CustomCode is used to simulate thick client actions.

Inside of our RPT code we use a custom-built JAVA Class called “MYSQL_IFACE” to create an interface

between our script and the database. This class was developed using the java.sql package, which is a

standard part of JDK.

We've also modified the SQL statement to use a variety of actor names which are read from a data file,

preventing database caching, making the test more realistic.


Execution

The final step is to execute the test and collect the results. We monitor response time, transaction

verdicts, application errors, and server resources.

Conclusion Thick client application and database volume testing is entirely possible with the right set of tools and

the knowledge to implement them correctly.


About the Author Alex Makletsov is a Senior Engineer with expertise in performance testing, tuning, scaling, capacity, and application security. Alex has comprehensive knowledge of application lifecycle management (ALM) solutions, software quality assurance (SQA) best practices, and technology to business relations. He has extensive experience providing services for financial, pharmaceutical, retail, and utility industries.

Alex lives in the East Village section of Manhattan (NY) and can be found doing home automation, DIY, bouldering and drinking craft beer.

About RTTS RTTS is the leading provider of QA and testing solutions for critical business applications. Headquartered in New York and with offices in Philadelphia, Atlanta and Phoenix, RTTS has been serving Fortune 500 and mid-sized companies worldwide since 1996. We offer the most comprehensive suite of quality assurance solutions, and we've helped 600+ organizations drive positive results from their software development, integration and data quality projects.

RTTS has cultivated partnerships with the world's leading software vendors, including IBM, Microsoft, HP, Oracle, Teradata, HortonWorks and Cloudera. We draw on our expertise utilizing our proven quality methodology, our in-house expert test engineers and best-of breed solutions.

More information can be found at www.rttsweb.com

http://www.rttsweb.com/