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