Test case generators are tools which are used to produce valuable test cases and data in order to test a given software. Since testing is complex, we cannot state a tool which serves exhaustively to every piece of software developed in each domain. There are four methods to generate test cases which are as follows:

1) Artificial Intelligence Based Test case Generators
A potent set of test case is the set of all test cases which are liable to uncover faults. Such faults are called potent faults, and vaguely defined. Since there are no boundaries which defined a potent fault, it is difficult to generate test case for uncovering faults.
A test adequacy criteria is the one which differentiate a good test set from a bad one. Coverage tests are one in which each and every line of software or code is tested in order to find fault. Branch coverage test is a simple form of coverage test which just tests at the branches and conditions.
Eg: if (a>=b) {do something}
else {do something else}
Multiple condition coverage tests are one which tests for boolean variables in conditions occurs at least once. If a test case which is difficult, which is the case similar with the halting problem which does not have a specific algorithm and difficult to solve it.
In order to handle such issues, we go for a heuristic approach to solve the problem of generating test cases. Here we use CBR - Case Based Reasoning for generation of test cases, by applying pre-fabricated tweaks for user defined test cases. In order to achieve this we use backward tracking method.
Eg: To prove at least once a < b

2) Use Case Based Test case Generators
A fact in today's industrial scenario is that we put 30 - 50% of total production cost for testing. Here we examine how use cases can be used to generate test cases.
An use case may be considered as a pictorial representation of any system that is based on UML -Unified Modeling Language specification.

An use case gives the following for various people:
i) Customer - What to expect?
ii) Developer - What to code?
iii) Technical Writer - What to document?
iv) Tester - What to test?

A use case scenario is one which is obtained from the use cases which are there in hand. They are :
a) Instance of an use-case.
b) Complete path through use case.
This use case scenario is used to generate test cases.
There are three steps to generate test case from use case:
1) From each use case generate a full set of scenario.
2) From each scenario, generate test cases and a condition that makes it to execute.
3) For each test case identify the data value to test.

3) Test case generation by Specification based Software Testing
This method generates test cases based on the functional specification and requirements of the software. Since this could be adopted from the first phase of the Software development life cycle, the amount of bugs in the software gets greatly reduced. There are some problems in transforming the functional specification. They are:
i) It must be user friendly ie., in a way that could be human readable.
ii) Also must be ina position to be converted into a machine readable form.
iii) Based on this we acquire a reasonably small set of test data input.
In order to achieve this we use a tool called CAT - Computer Assisted Testing which is still under implementation and is not complete. The CAT uses TSG - Test Script Graph and TSL - Test Script Language to convert functional specification to cases. It compiles a set of logic expressions and uses boolean reduction algorithm to reduce those expressions to a minimal form.

4) GNU/Linux as a Testing Tool

To me, all *NIX operating systems are a test tool in itself with remarkable functionality and the availability of many tools for them. My favorite one-liner is:

cat file1.txt|sort|uniq > file2.txt

This demonstrates perfectly what I mean. Say, for example, file1.txt contains the output of a database query. I sort the data, remove duplicates, and write the output into file2.txt, with one command. Instead of putting the output into another file, I could compare it with data from a previous test cycle using the powerful *diff* tool.