background image
<< Managing Datapool Files | Preparing a datapool >>
<< Managing Datapool Files | Preparing a datapool >>
Datapool Limits
Working with Datapools
Row Access Order
Row access order is the sequence in which datapool rows are accessed at test runtime.
With GUI scripts, you can control the row access order of the datapool cursor
through the
argument of the SQABasic
With session scripts, you can control row access order through the Access Order
setting in the Robot Configure Datapool in Test Script dialog box. (See page 10-16.)
Datapool Limits
A datapool can have up to 150 columns if the Rational Test software automatically
generates the data for the datapool, or 32,768 columns if you import the datapool
from a database or other source. Also, a datapool can have up to 2,147,483,647 rows.
What Kinds of Problems Does a Datapool Solve?
If you play back a script just once during a test run, that script probably does not need
to access a datapool.
But often during a test run, and especially during performance testing, you need to
run the same script multiple times -- for example:
During performance testing, you will probably want to run multiple instances
of a script, so that the script is executed many times simultaneously.
(Remember, a virtual tester is one runtime instance of a script.)
During functional and performance testing, you will often want to run multiple
iterations of a script, so that the script is executed many times consecutively
(simulating a virtual tester performing the same task over and over).
If the values used in each script instance and each script iteration are the same literal
values -- the values you provided during recording -- you might encounter
problems at test runtime.
Here are some examples of problems that datapools solve:
Problem: During recording, you create a personnel file for a new employee, using
the employee's unique social security number. Each time the script is played
back, there is an attempt to create the same personnel file and supply the same
social security number. The application rejects the duplicate requests.
Solution: Use a datapool to send different employee data, including unique social
security numbers, to the server each time the script is played back.