TestBytes 4.0 from Logic Works Inc.
- By Dan Romanchik
- July 13, 2001
Testing is no fun. Generating test data is really no fun. Even so, the validity of a test often depends on how
well your test data matches real-world data. This is certainly true when testing a database application. If the
database does not contain appropriate data, there is a good chance that your tests will not really tell you whether
or not your application will work right when you put it into production.
To populate a database, there are several approaches you can take. One thing you can do is sit someone down
at a keyboard and fill records with random data. If you do not have an intern you can assign to this task, it is
a good chance your carpal-tunnel syndrome will be aggravated and the data will probably not be all that great.
You will have lots of columns with the strings "asdf" and the number "1234" in them.
Another approach is to write a program to populate the database. If you use this approach, your database will
have meaningful data, but you will have wasted a good bit of time in the process.
A third approach is to keep copies of old
|Standard data profiles in TestBytes 4.0 include first names, last names, street addresses, state
abbreviations, company names, phone numbers and several other types of data.
databases whose data closely resembles the data you will need to test the new database. Unfortunately, there are
several drawbacks to this approach. First, if the database is large, you will need lots of disk space to accommodate
the data. Second, you may have a security problem if the database contains items such as credit card numbers or
You could also use TestBytes 4.0 from Logic Works Inc., Princeton, N.J. With TestBytes, you can quickly populate
databases with many different types of test data, not just random alphanumeric data. One of the ways to do this
is to use the standard data profiles included with the package. Standard data profiles in TestBytes 4.0 include
first names, last names, street addresses, state abbreviations, company names, phone numbers and several other
different types of data commonly found in databases.
If the standard data profiles just do not cut it, you can create your own profiles. For example, one of the
databases that I am currently working with uses a five-digit number company code. Using the custom profile dialog
box, I quickly defined a new data profile and used the profile to fill up this column.
The new version of TestBytes takes this one step further, though. With TestBytes 4.0 not only can you define
the size and type of the test data, you can define data types with multiple segments. My database, for example,
has a field which contains E-mail addresses. Since there was no standard data profile for E-mail addresses, I had
to create a custom profile.
Again using the custom profile dialogue box, I created a five-segment data pattern. For the first segment, I
used the standard profile for first names, the second segment is the character '@,' the third segment is a random
alphanumeric field between one and ten characters long, and the fourth segment is a period, or "dot."
For the fifth segment, I created a list, with the values "com," "org," and "edu."
The custom profiling feature of TestBytes has a couple of other features which I found useful. First, the dialogue
box displays sample data. This lets you verify that the data pattern you set up is actually what you want before
you close the dialogue box and populate the database. Second, you can specify the percentage of fields to leave
Once you have defined the data profiles, you can begin to populate the database. You can do this manually, as
I did, using the data-generation dialogue box to specify the data profile for each field in a table. If you have
many tables, however, you may want to use the multi-table script builder to generate data for multiple tables simultaneously.
This feature greatly reduces the amount of time needed to populate a database with data.
An important feature of TestBytes is its support of referential integrity (RI). What this means is that fields
linked between two tables will contain common data. In my database, the company code field is found in two of the
database's three tables. Once I defined the relationship between the tables, TestBytes knew to populate the column
in the child table with data found only in the parent table.
There are several ways to define the parent-child relationships. You can do it manually as I did above, or you
can use data models generated by Logic Works' ERwin data-modeling tool. A third way is to let TestBytes use the
database under test, assuming that you have implemented referential integrity on the database.
Logic Works ships TestBytes 4.0 on CD-ROM, with a 32-bit version for Windows 95 and Windows NT systems as well
as a 16-bit version for Windows 3.1. Installation on my Windows 95 machine was straightforward and quick. It uses
the standard Windows 95 setup program and took less than 10 minutes to install. The package also comes with a well-written,
spiral-bound user's guide, a nicety that's becoming more and more rare these days. The user's manual even included
a section on how to define ODBC data sources under Windows 95.
To run TestBytes 4.0 you need a 486 or Pentium processor, Windows 3.x, Windows 95 or Windows NT, 10 Mb of hard
disk space and at least 16 Mb of RAM.
Dan Romanchik is an engineering manager turned writer and Web developer. His current passion is amateur radio. You can read his amateur radio blog at www.blurty.com/~kb6nu.