-Now, let's go back to our systematic functional testing - -2
-approach and all the steps in this process. So - -3
-far we've seen the first step and the second - -4
-step. Now we're going to look at this step in which, - -5
-once we have identified the values of interest, we - -6
-derive test case specifications for these values, or using these - -7
-values. And the test case specification defines how the - -8
-values should be put together when actually testing the system. - -9
-And test case specification describe how these values should be put - -10
-together when testing the system. So let me go back one more - -11
-time to our split program, so that we can use the - -12
-information that we already computed. At this point what we have is - -13
-some possible inputs for "string," our first parameter, and for "size," - -14
-our second parameter. And we want to put them together, to generate - -15
-the description of what the test case should be. So let - -16
-me once more rearrange this a little bit. I first remove the - -17
-description of the subdomains, because we won't use them in this step. - -18
-And I moved out the set of all our possible inputs, that we're - -19
-going to combine to create the test case specification. And one possible way - -20
-of doing that is simply to combine the values for the first parameter, - -21
-and the values for the second parameter. So the Cartesian product. So - -22
-if we do that, what we will obtain is, for example, if we - -23
-consider the first possible input, size is equal to minus 1, we can - -24
-combine it with these two possible inputs for string, and we will get - -25
-size is equal to minus 1 string with length minus 2, or - -26
-size is equal to minus 1 string with length minus 1. And we'll - -27
-go back in a second to see what this means. Now if we - -28
-consider the second possible value for size, size is equal to one, we - -29
-also have two cases so the first one in this case that will - -30
-be considered a string with length zero. So the antistring. And we can - -31
-continue combining this value, but one thing I want to point out is - -32
-that if we just go in this straight forward and brute force sort - -33
-of way, we will obtain many combinations that don't make any sense, - -34
-like for example, this combination which doesn't make any sense because we can - -35
-not create the string with length minus 2. Similar for this combination, because - -36
-then by the same token, we cannot raise things with length minus 1. - -37
-And so there's a lot of cases that we will have to eliminate - -38
-afterwards. So what we're going to see in a few minutes is a possible - -39
-way in which we can avoid producing these meaningless cases. And at the - -40
-same time, keep under control, the number of test cases that we generate. - -41
-So lets go back for the last time to our steps - -42
-for systematic functional testing. What we just did was to derive - -43
-test case specification from a set of relevant inputs. The following - -44
-step is to use these test case specifications to generate actual test - -45
-cases. And this is normally a fairly mechanical step in the - -46
-sense that we just have to instantiate what is in the test - -47
-case specification as actual test cases. And it's really dependent on - -48
-the specific type of partitions and values identified on the specific context. - -49
-So instead of looking at that here in the, in the abstract, - -50
-I'm going to show you with an example later on, in the lesson. -- cgit 1.4.1