Before getting to our demo, we still have two steps to consider.
The first step corresponds to the identification of the test case specifications
in our general systematic approach. And in fact, it's called produce and
evaluate test case specifications. This is a step than can be completely
automated given the results of the previous steps. And the final result
of this step is the production of a set of test frames.
Where a test frame is the specification of a test. Let me
show you an example of this. What we are looking at here
is a test frame for the program split. Test frames are normally
identified by a sequence number. But in this case we are looking at
the 30th six test frame. And what they do is simply to
specify the characteristic of the inputs for that test. In this case, since
we have two inputs, we have two entries, the first one for
string str tells us that the length of the string has to be
size minus 1, and that the string has to contain special characters. And
for size, it tells us that the value of size has to be
greater than zero. As the title says, this step is meant
to produce but also evaluate the case specification. What does it mean
to evaluate? One of the advantages of this approach is that we
can easily use it to assess how many test frames and therefore
how many test cases we will generate with the current least
of categories, choices and constraints. And the beauty of this is that
if the number is too large we can just add additional constraints
and reduce it. And given then the step is automated we just
add constraints push a button and we get our new set of
test frames. And again we can have a wait it either go
hat or add more constraints if we need to further reduce it
and this is something else that we will see in our demo.