The Oracle Application Testing Suite (ATS) is a comprehensive testing solution with built-in support for testing Application Development Framework (ADF) applications. In many testing scenarios, user accounts can be generated once and used again and again when testing various functional areas. These user accounts could be created by a script or even created manually. Some testing scenarios, however, require that user accounts can only be used once. In this case, user accounts must be generated by one script and then consumed by another script. Once a particular user account is consumed, that user account cannot be used again. This blog post shows how to create that link between the script that generates the user accounts and the script that consumes those accounts.
When using ATS, the usual first step is to create functional test scripts, which do full browser emulation. Once the use cases are further refined, load test scripts are recorded that only do the raw interaction, such as HTML "post" and "get" commands. These load test scripts often require blocks of user accounts, to allow the scripts to log into the customer application and perform the activities being tested. This article addresses the situation where load test scripts require user accounts that can only be used once for a set of activities. For example, the customer application might be conducting a survey where each person is only allowed to vote once. To load test this application, fresh users would be needed for each test run.
Typically, creating a user account requires a block of information about the user, such as first name, last name, address, city, state, etc. Additionally, there might be a user ID and password, plus answers to security questions, as security credentials for the account. Since each user account can only be used once, certain values must be unique and not repeated. The customer application would dictate exactly which fields must have unique values, but common fields are user ID, name, and telephone number.
ATS load test scripts use databanks to supply the values for each new iteration of the script. This databank is a CSV file that contains rows of values for all of the fields that will be supplied to the customer application. In the ATS Java code of the script, using the databank looks like this:
A snippet of the CSV file, with the header as the first line, would look like this:
"FIRSTNAME","MIDDLE","LASTNAME","ADDDRESS1","CITY","STATE","ZIPCODE","USERACCT","PW" "FPT1010914I1","MPT1010914I1","LPT1010914I1","213 Maple Street","Waco","PA","123456","PT1010914I1","Welcome1!" "FPT1010914I2","MPT1010914I2","LPT1010914I2","423 Elm Street","Pittsburgh","TX","234567',"PT1010914I2","Welcome1!"
The databank file itself would need to be generated, so that the ATS script could use those databank values to create user accounts in the customer's application. This can be done using spreadsheet tools or a scripting tool like Python. Note that certain fields have the unique values required by the customer's application. In this example, the unique fields include a representation of the date the databank was generated and a sequence number within that databank.
So, before the "create account" ATS script is run, a databank would be generated containing unique, new values. Those values would be used by the script to generate new user accounts in the customer's application.
As noted above, the ATS load test script gets a new row from the databank each time a user account is created. However, not all iterations are going to be successful. If that "create account" script iteration fails for any reason, that row from the databank should not be used in any subsequent steps. To ensure that only successful iterations are subsequently used, a log message should be added at the end of the script. This log message is carefully crafted to recreate the row in the databank that was initially loaded by the getNextDatabankRecord call. An example log message, matching the format above, would be:
Note the specific use of the backslash (\) to "escape" the double-quote characters. By putting this log statement at the end of the script, only successful iterations will get logged. If any errors occurred, exceptions would be thrown and processing interrupted for that iteration. Also note the CREATEACCOUNT value at the start of the log message. This is used to search through the log file and extract only the databank rows. The actual value should be something that would never otherwise appear in any of the log messages, so that only valid databank rows get extracted from the log files.
The actual extraction can be done with most any search tool, like the "grep" command, such as:
grep CREATEACCOUNT ats_log_file.log > valid_account_values.txt
Since this new databank will only have the actual rows of data, the header line needs to be copied over from the original databank file. To streamline the process, create a file that contains just the header line and name it "header.txt" in the same directory as the extracted log files. Then, a simple "cat" command can be used to create the final databank, like this:
cat header.txt valid_account_values.txt > valid_accounts_databank.csv
These separate steps can easily be combined into a single shell script to make the extraction process streamlined and reliable. This shell script could also have statements to remotely copy the ATS log files, for situations where the ATS testing agents are on different servers.
The end result of the previous steps is a CSV file, complete with header, of only those databank records where an account was successfully created. Any subsequent script that needs to consume those accounts simply needs to point to the generated databank. This can be accomplished by either copying the generated databank to the subsequent script directory and keeping the same name, or modifying the subsequent script to reference the generated databank file name.
Here is a high-level description of the steps, including the recommended tools: