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
|
1
00:00:00,140 --> 00:00:02,690
So what is the starting point of black box testing? Black
2
00:00:02,690 --> 00:00:06,010
box testing start from a description of the software or as we
3
00:00:06,010 --> 00:00:09,590
call it, a functional specification. And the final result of black
4
00:00:09,590 --> 00:00:12,760
box testing is a set of test cases, a set of actual
5
00:00:12,760 --> 00:00:16,410
inputs and corresponding outputs that we can use to exercise our
6
00:00:16,410 --> 00:00:19,030
code and to try to find defects in our code. So the
7
00:00:19,030 --> 00:00:22,060
question is, how do we get from functional specification to test
8
00:00:22,060 --> 00:00:25,510
cases? Doing these derivations, so going from this description to a concrete
9
00:00:25,510 --> 00:00:28,550
set of tests, is a very complex analytical process.
10
00:00:28,550 --> 00:00:31,220
And normally brute force generation is not a good
11
00:00:31,220 --> 00:00:34,430
idea because it's inefficient and ineffective. What we want
12
00:00:34,430 --> 00:00:37,540
to do instead is to have a systematic approach to
13
00:00:37,540 --> 00:00:40,250
derive test cases from a functional specification. What a
14
00:00:40,250 --> 00:00:43,970
systematic approach does is to simplify the overall problem by
15
00:00:43,970 --> 00:00:48,320
dividing the process into elementary steps. In particular, in
16
00:00:48,320 --> 00:00:50,520
this case, we will perform three main steps. The first
17
00:00:50,520 --> 00:00:55,790
step is to identify independently testable features. Individual features in
18
00:00:55,790 --> 00:00:57,600
the soft hood that we can test. And we're going to
19
00:00:57,600 --> 00:00:59,990
expand on each one of these steps in the next
20
00:00:59,990 --> 00:01:02,490
part of the lesson. The following step is once we have
21
00:01:02,490 --> 00:01:06,000
these independently testable features to identify what are the relevant
22
00:01:06,000 --> 00:01:08,590
inputs. So what are the inputs or the behavior that is
23
00:01:08,590 --> 00:01:11,610
worth testing for these features. Next once we have these
24
00:01:11,610 --> 00:01:13,020
inputs, we're going to derive test
25
00:01:13,020 --> 00:01:15,770
specifications. And test case specifications are
26
00:01:15,770 --> 00:01:19,490
description of the test cases that we can then use
27
00:01:19,490 --> 00:01:23,270
to generate actual test cases. And proceeding in this way,
28
00:01:23,270 --> 00:01:26,050
by this steps, has many advantages. It allows for the
29
00:01:26,050 --> 00:01:29,920
coupling different activities. It allows for dividing brain intensive steps from
30
00:01:29,920 --> 00:01:32,240
steps that can be automated, which is a great advantage.
31
00:01:32,240 --> 00:01:34,980
And also we will see, it allows you for monitoring
32
00:01:34,980 --> 00:01:38,040
the testing process. So to figure out whether your testing
33
00:01:38,040 --> 00:01:41,000
process is going as expected, for example, if you're generating too
34
00:01:41,000 --> 00:01:44,160
many test cases. Or you're generating the number of test cases that your
35
00:01:44,160 --> 00:01:47,880
amount of resources available allows you to run. So let's start by looking
36
00:01:47,880 --> 00:01:51,230
at the first step of this process in which our goal is to
37
00:01:51,230 --> 00:01:54,820
go from a Functional Specification to a set of features that we can
38
00:01:54,820 --> 00:01:57,700
test in the software. So what we want to do is to identify all
39
00:01:57,700 --> 00:02:00,290
of the feature of the software. And why do we want to do this?
40
00:02:00,290 --> 00:02:02,650
Well you know, in the spirit of breaking down the complexity of the
41
00:02:02,650 --> 00:02:06,170
problem, it does not make sense to just try to devise test cases for
42
00:02:06,170 --> 00:02:08,750
all the features of the software at once. For any non-trivial
43
00:02:08,750 --> 00:02:11,980
software, that's a humongous problem, and something that we cannot really
44
00:02:11,980 --> 00:02:16,300
handle effectively. A much better way is to identify independently testable
45
00:02:16,300 --> 00:02:19,100
features and consider one of them at a time when generating tests.
|
