Test data

Usually you will get test data from DBA’s. While developing the script itself, we have to prepare a test data requirement sheet which contains which required for every use case how much test data you required and segregate which is reusable and which is not.Sometimes you can generate test data using LR script itself.
Example: You can create username and password if the signup functionality is available in the
application. If the functionality is not available to generate test data, we have to request DBA to provide it.
If the test data is not reusable, we have to request DBA to create database restoration point or take the flashback of database.

Scenario 1: Once the test is completed, we have to request DBA to change DB to previous restoration point. So that data will be available for next test.

Scenario 2: Once the test is completed, we have to request DBA, flashback the database or load previous database instance.

Scenario 3:
Q: One of the script is generating purchase order number and second script is processing same purchase order number.

What is your approach to design the script?
Or
How to pass value from one script to another?

Solution 1: Create two actions in one script for both of the scenarios. Capture purchase order number from 1st action and pass into the second action.

Solution 2:
Data Staging:
Execute the first script with multiple users in controller. Write purchase order numbers into local file before starting actual test. Copy purchase order numbers from local file. Load into second
script so that both of the script will execute simultaneously.

Solution 3:
VTS (Virtual Table Server):
Virtual Table Server is a tool that enables sharing of test data and parameters between Load Runner Virtual Users (VUsers). Usually performance testers use parameterization in their
scripts, but in Virtual Table Server it acts as centralized repository to store data which can be shared between VUsers during the test execution.