How to generate test data for all the tables in oracle

Question

I am planning to use plsql to generate the test data in all the tables in schema, schema name is given as input parameters, min records in master table, min records in child table. data should be consistent in the columns which are used for constraints i.e. using same column value..
planning to implement something like
execute sp_schema_data_gen (schemaname, minrecinmstrtbl, minrecsforchildtable);
schemaname = owner,
minrecinmstrtbl= minimum records to insert into each parent table,
minrecsforchildtable = minimum records to enter into each child table of a each master table;
all_tables where owner= schemaname;
all_tab_columns and all_constrains - where owner =schemaname;
using dbms_random pkg.
is anyone have better idea to do this.. is this functionality already there in oracle db?

Answer 1

Ah, damorgan, data, test data, metadata and table-driven processes. Love the stuff!
There are two approaches you can take with this. I'll mention both and then ask which
one you think you would find most useful for your requirements.
One approach I would call the generic bottom-up approach which is the one I think you
are referring to.
This system is a generic test data generator. It isn't designed to generate data for any
particular existing table or application but is the general case solution.
Building on damorgan's advice define the basic hierarchy: table collection, tables, data; so start at the data level.
1. Identify/document the data types that you need to support. Start small (NUMBER, VARCHAR2, DATE) and add as you go along
2. For each data type identify the functionality and attributes that you need. For instance for VARCHAR2
a. min length - the minimum length to generate
b. max length - the maximum length
c. prefix - a prefix for the generated data; e.g. for an address field you might want a 'add1' prefix
d. suffix - a suffix for the generated data; see prefix
e. whether to generate NULLs
3. For NUMBER you will probably want at least precision and scale but might want minimum and maximum values or even min/max precision,
min/max scale.
4. store the attribute combinations in Oracle tables
5. build functionality for each data type that can create the range and type of data that you need. These functions should take parameters that can be used to control the attributes and the amount of data generated.
6. At the table level you will need business rules that control how the different columns of the table relate to each other. For example, for ADDRESS information your business rule might be that ADDRESS1, CITY, STATE, ZIP are required and ADDRESS2 is optional.
7. Add table-level processes, driven by the saved metadata, that can generate data at the record level by leveraging the data type functionality you have built previously.
8. Then add the metadata, business rules and functionality to control the TABLE-TO-TABLE relationships; that is, the data model. You need the same DETPNO values in the SCOTT.EMP table that exist in the SCOTT.DEPT table.
The second approach I have used more often. I would it call the top-down approach and I use
it when test data is needed for an existing system. The main use case here is to avoid
having to copy production data to QA, TEST or DEV environments.
QA people want to test with data that they are familiar with: names, companies, code values.
I've found they aren't often fond of random character strings for names of things.
The second approach I use for mature systems where there is already plenty of data to choose from.
It involves selecting subsets of data from each of the existing tables and saving that data in a
set of test tables. This data can then be used for regression testing and for automated unit testing of
existing functionality and functionality that is being developed.
QA can use data they are already familiar with and can test the application (GUI?) interface on that
data to see if they get the expected changes.
For each table to be tested (e.g. DEPT) I create two test system tables. A BEFORE table and an EXPECTED table.
1. DEPT_TEST_BEFORE
     This table has all EMP table columns and a TEST_CASE column.
     It holds EMP-image rows for each test case that show the row as it should look BEFORE the
     test for that test case is performed.
     CREATE TABLE DEPT_TEST_BEFORE
     TESTCASE NUMBER,
     DEPTNO NUMBER(2),
     DNAME VARCHAR2(14 BYTE),
     LOC VARCHAR2(13 BYTE)
2. DEPT_TEST_EXPECTED
     This table also has all EMP table columns and a TEST_CASE column.
     It holds EMP-image rows for each test case that show the row as it should look AFTER the
     test for that test case is performed.
Each of these tables are a mirror image of the actual application table with one new column
added that contains a value representing the TESTCASE_NUMBER.
To create test case #3 identify or create the DEPT records you want to use for test case #3.
Insert these records into DEPT_TEST_BEFORE:
     INSERT INTO DEPT_TEST_BEFORE
     SELECT 3, D.* FROM DEPT D where DEPNO = 20
Insert records for test case #3 into DEPT_TEST_EXPECTED that show the rows as they should
look after test #3 is run. For example, if test #3 creates one new record add all the
records fro the BEFORE data set and add a new one for the new record.
When you want to run TESTCASE_ONE the process is basically (ignore for this illustration that
there is a foreign key betwee DEPT and EMP):
1. delete the records from SCOTT.DEPT that correspond to test case #3 DEPT records.
          DELETE FROM DEPT
          WHERE DEPTNO IN (SELECT DEPTNO FROM DEPT_TEST_BEFORE WHERE TESTCASE = 3);
2. insert the test data set records for SCOTT.DEPT for test case #3.
          INSERT INTO DEPT
          SELECT DEPTNO, DNAME, LOC FROM DEPT_TEST_BEFORE WHERE TESTCASE = 3;
3 perform the test.
4. compare the actual results with the expected results.
     This is done by a function that compares the records in DEPT with the records
     in DEPT_TEST_EXPECTED for test #3.
     I usually store these results in yet another table or just report them out.
5. Report out the differences.
This second approach uses data the users (QA) are already familiar with, is scaleable and
is easy to add new data that meets business requirements.
It is also easy to automatically generate the necessary tables and test setup/breakdown
using a table-driven metadata approach. Adding a new test table is as easy as calling
a stored procedure; the procedure can generate the DDL or create the actual tables needed
for the BEFORE and AFTER snapshots.
The main disadvantage is that existing data will almost never cover the corner cases.
But you can add data for these. By corner cases I mean data that defines the limits
for a data type: a VARCHAR2(30) name field should have at least one test record that
has a name that is 30 characters long.
Which of these approaches makes the most sense for you?