Changing a hard-coded password in multiple tests in Performance Tester

Let's say a large number of tests that were recorded require a user ID and password to log in.  At any point in time, when a password is changed, the password must be changed in all the tests. 

Each test can be manually edited to change the password, and this would resolve the issue.  However, this process is tedious and time-consuming. Also, if the password needs to be changed later, then it would require editing all of the tests again.

So, here’s a better way to handle this.

Step 1 - Create a datapool

​This functionality has been around for a long time.  The first step is to add a datapool, which is done in the Test Details section of the test.  Performance Tester will use the name of the test as the name of this datapool.  Complete the required options in the dialog box and let the datapool have one column with an entry, "password".

Here's the resulting datapool.
​

Step 2 - Substitute an existing hard-coded password with the datapool value

The easiest way to find an existing password is to do a test search on the HTTP Requests POST content.  So, right-click the top node of the test and select Test Search.

​Enter the value of the old password as the text to search for.  Then press the Search button.

The Search function will show all matches in POST content that have the old password value.  Since most tests will only have one login request, we will usually find one match.

​Double-click the result in the Search results pane and it'll directly show the POST content of the request that contains the password.

​Right-click the password and choose Substitute > Select Data Source...

Select the "password" variable of the datapool that we just created and complete the required options in the dialog box and save the test.
​

Step 3 - Save the test and create a data correlation rules file

​Click Yes when the following prompt appears.

Provide a name to the rules file, and then complete the required options in the dialog box.  For example, the rules file is called UpdatePasswords.
​

Step 4 - Edit the datapool

​When the datapool is automatically created, it is created with a name, number of columns, header, and one row. However, the value of the datapool variable is null.  We need to set it to the value of the new password.  Simply edit the datapool and add the new password value as shown in the following screenshot.

Step 5 - Apply the data correlation rules to the remaining tests

So far, we updated the password in a single test.  The upcoming password updates are made easier by mapping the old password value to a datapool value.   We need not do a test search and change the password in the test.  We need not even edit the test. We just need to add the new password value as shown in step 4.

This process is a bit tedious and we have other tests that need their passwords changed.   So, instead of repeating the manual steps, we can apply the data correlation rules file that we made earlier to the remaining  tests. Performance Tester will do all the hard work for us!

So, the next step is to select all the remaining tests and right-click and choose Apply data correlation rules...

Click Add to add the rule that we made in step 3, and then click Finish.
​

In mere moments, Performance Tester makes all the changes to these remaining tests that we did manually on the test we used in steps 1 through 3.

Let's look at a random test for a sanity check:

​Here's our datapool and it's “Used by 1”.  This means it’s substituted in the test 1 time.

Click the + sign and expand the Column node and double-click Substituter.  Performance Tester will get on to the place in the test where this substitution will take place.  

​The text "oldpassword" is now highlighted in green, which means it will be substituted at a runtime with the datapool value.
​

We just saw how using data correlation rules in HCL OneTest Performance makes it easy to maintain tests.  Going forward, to change the passwords for all the tests, we just need to edit a single row in a single datapool.

​If you haven't used a rules file before, this is a good first use case and hope you find it useful.

Paul Liskay
Senior Test Manager

---

Paul Liskay joined the Rational team in 2009.  Currently, he is a Level 2 support engineer for the Rational Testing Tools for the US geography, focusing on Rational Performance Tester, Rational Integration Tester, and Rational Functional Tester.   Before joining the support team, he has led the teams for the Rational Integration Tester 8.0 release, for Rational Performance Tester for the 8.0 through 8.2 releases.  He was also with the system test team for Rational Team Concert for the 4.0 release.