1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
|
1
00:00:00,140 --> 00:00:02,790
Now, let's go back to our systematic functional testing
2
00:00:02,790 --> 00:00:05,540
approach and all the steps in this process. So
3
00:00:05,540 --> 00:00:07,680
far we've seen the first step and the second
4
00:00:07,680 --> 00:00:10,340
step. Now we're going to look at this step in which,
5
00:00:10,340 --> 00:00:13,290
once we have identified the values of interest, we
6
00:00:13,290 --> 00:00:18,110
derive test case specifications for these values, or using these
7
00:00:18,110 --> 00:00:21,300
values. And the test case specification defines how the
8
00:00:21,300 --> 00:00:25,230
values should be put together when actually testing the system.
9
00:00:25,230 --> 00:00:29,110
And test case specification describe how these values should be put
10
00:00:29,110 --> 00:00:32,360
together when testing the system. So let me go back one more
11
00:00:32,360 --> 00:00:34,780
time to our split program, so that we can use the
12
00:00:34,780 --> 00:00:37,450
information that we already computed. At this point what we have is
13
00:00:37,450 --> 00:00:41,670
some possible inputs for "string," our first parameter, and for "size,"
14
00:00:41,670 --> 00:00:44,410
our second parameter. And we want to put them together, to generate
15
00:00:44,410 --> 00:00:47,080
the description of what the test case should be. So let
16
00:00:47,080 --> 00:00:50,420
me once more rearrange this a little bit. I first remove the
17
00:00:50,420 --> 00:00:53,360
description of the subdomains, because we won't use them in this step.
18
00:00:53,360 --> 00:00:55,800
And I moved out the set of all our possible inputs, that we're
19
00:00:55,800 --> 00:00:59,470
going to combine to create the test case specification. And one possible way
20
00:00:59,470 --> 00:01:03,320
of doing that is simply to combine the values for the first parameter,
21
00:01:03,320 --> 00:01:06,370
and the values for the second parameter. So the Cartesian product. So
22
00:01:06,370 --> 00:01:09,060
if we do that, what we will obtain is, for example, if we
23
00:01:09,060 --> 00:01:12,470
consider the first possible input, size is equal to minus 1, we can
24
00:01:12,470 --> 00:01:15,510
combine it with these two possible inputs for string, and we will get
25
00:01:15,510 --> 00:01:18,680
size is equal to minus 1 string with length minus 2, or
26
00:01:18,680 --> 00:01:21,680
size is equal to minus 1 string with length minus 1. And we'll
27
00:01:21,680 --> 00:01:24,200
go back in a second to see what this means. Now if we
28
00:01:24,200 --> 00:01:27,510
consider the second possible value for size, size is equal to one, we
29
00:01:27,510 --> 00:01:30,260
also have two cases so the first one in this case that will
30
00:01:30,260 --> 00:01:34,030
be considered a string with length zero. So the antistring. And we can
31
00:01:34,030 --> 00:01:37,410
continue combining this value, but one thing I want to point out is
32
00:01:37,410 --> 00:01:40,570
that if we just go in this straight forward and brute force sort
33
00:01:40,570 --> 00:01:43,390
of way, we will obtain many combinations that don't make any sense,
34
00:01:43,390 --> 00:01:46,500
like for example, this combination which doesn't make any sense because we can
35
00:01:46,500 --> 00:01:50,410
not create the string with length minus 2. Similar for this combination, because
36
00:01:50,410 --> 00:01:53,190
then by the same token, we cannot raise things with length minus 1.
37
00:01:53,190 --> 00:01:55,730
And so there's a lot of cases that we will have to eliminate
38
00:01:55,730 --> 00:01:59,380
afterwards. So what we're going to see in a few minutes is a possible
39
00:01:59,380 --> 00:02:02,970
way in which we can avoid producing these meaningless cases. And at the
40
00:02:02,970 --> 00:02:06,380
same time, keep under control, the number of test cases that we generate.
41
00:02:06,380 --> 00:02:09,070
So lets go back for the last time to our steps
42
00:02:09,070 --> 00:02:11,980
for systematic functional testing. What we just did was to derive
43
00:02:11,980 --> 00:02:15,040
test case specification from a set of relevant inputs. The following
44
00:02:15,040 --> 00:02:18,420
step is to use these test case specifications to generate actual test
45
00:02:18,420 --> 00:02:21,170
cases. And this is normally a fairly mechanical step in the
46
00:02:21,170 --> 00:02:23,900
sense that we just have to instantiate what is in the test
47
00:02:23,900 --> 00:02:27,970
case specification as actual test cases. And it's really dependent on
48
00:02:27,970 --> 00:02:32,300
the specific type of partitions and values identified on the specific context.
49
00:02:32,300 --> 00:02:35,100
So instead of looking at that here in the, in the abstract,
50
00:02:35,100 --> 00:02:37,480
I'm going to show you with an example later on, in the lesson.
|
