about summary refs log tree commit diff
path: root/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt
blob: f88905797974418f046e64ab3ba5fa37050263d9 (plain) (blame)
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
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
1
00:00:00,140 --> 00:00:03,010
In this example, we're going to start from an informal specification, and the

2
00:00:03,010 --> 00:00:06,670
specification is the one shown here in file spec.txt. This is the

3
00:00:06,670 --> 00:00:10,210
specification for the maintenance function in a specific system. So what we're

4
00:00:10,210 --> 00:00:13,630
doing is that we're taking the description of the functionality of a system,

5
00:00:13,630 --> 00:00:16,219
and we're building a model, in this case a final state machine

6
00:00:16,219 --> 00:00:18,710
for it. And there is no need to look at all the details

7
00:00:18,710 --> 00:00:21,350
for this specification, but I want to point out that if you

8
00:00:21,350 --> 00:00:25,640
look at the way the specification is written, we can identify specific cases

9
00:00:25,640 --> 00:00:28,210
that we need to take into account. Like here if something

10
00:00:28,210 --> 00:00:31,920
happens, something else will follow. Again, if something happens something else

11
00:00:31,920 --> 00:00:35,690
will follow. So we have multiple choices here. Here will determine

12
00:00:35,690 --> 00:00:38,140
the next steps and so on. So all we have to

13
00:00:38,140 --> 00:00:42,420
do is to go through this process, identify these cases and

14
00:00:42,420 --> 00:00:45,300
then build a machine that represents these cases. For the spec

15
00:00:45,300 --> 00:00:47,830
that we just consider this is the state machine that will

16
00:00:47,830 --> 00:00:50,960
result. Again there is no need to go through all the details,

17
00:00:50,960 --> 00:00:53,090
but what I want to point out is that we have

18
00:00:53,090 --> 00:00:55,710
a set of states. So for instance, we have state zero,

19
00:00:55,710 --> 00:00:58,380
which is no maintenance, and if a request comes in, the

20
00:00:58,380 --> 00:01:01,350
system will move, and the system wait for pickup. Then if

21
00:01:01,350 --> 00:01:04,400
the pickup actually occurs, the system will move to the repair

22
00:01:04,400 --> 00:01:07,540
state, and so on and so forth. So this is just

23
00:01:07,540 --> 00:01:13,070
a more systematic representation of what was in the former specification.

24
00:01:13,070 --> 00:01:16,160
And I will argue that this is much easier to understand at

25
00:01:16,160 --> 00:01:19,170
least for somebody who has to develop tests for this system. In

26
00:01:19,170 --> 00:01:21,770
fact what we're going to see next is how we can go from that

27
00:01:21,770 --> 00:01:24,790
representation to a set of test cases. And the way which we do

28
00:01:24,790 --> 00:01:28,950
it is by covering the behaviors represented by defining state machine. And we

29
00:01:28,950 --> 00:01:31,500
can decide how we want to cover them. For example we might want

30
00:01:31,500 --> 00:01:35,080
to cover all the states. So we might want to identify paths in

31
00:01:35,080 --> 00:01:38,310
the state machine that go through all the states in the machine. Like

32
00:01:38,310 --> 00:01:41,840
the one I just draw or this one, this one and this one.

33
00:01:41,840 --> 00:01:44,900
So if we consider these four test cases, we can see that all the

34
00:01:44,900 --> 00:01:48,470
states in my system or at least all the states that I have identified

35
00:01:48,470 --> 00:01:51,450
are covered. I might want to go a little further, and decide that I

36
00:01:51,450 --> 00:01:54,210
don't only want to cover all of the states, but I want to cover, all

37
00:01:54,210 --> 00:01:57,930
of the transitions, because, it makes sense to visit a state, when coming from

38
00:01:57,930 --> 00:02:00,380
different states. And, if I want to do that, and I look at the

39
00:02:00,380 --> 00:02:03,440
test cases that I generated so far, I can see that there is one

40
00:02:03,440 --> 00:02:06,910
transition, the one here, that is not covered. And, the same can be said for

41
00:02:06,910 --> 00:02:09,210
the two transitions here. So what I can decide to do is

42
00:02:09,210 --> 00:02:13,370
to generate another test case, that covers those or extend an existing one.

43
00:02:13,370 --> 00:02:16,500
For instance, I could extend this test case by adding a visit to

44
00:02:16,500 --> 00:02:20,760
the state, before going back to these two. Alternatively, I could also generate

45
00:02:20,760 --> 00:02:24,390
new test cases, such as this one. To cover the missing transitions.

46
00:02:24,390 --> 00:02:26,350
And once I have these test cases, I can express them in a

47
00:02:26,350 --> 00:02:29,860
clearer way by simply specifying what are the states that they cover. I'm

48
00:02:29,860 --> 00:02:31,990
just going to give you a couple of examples. Say, if we look

49
00:02:31,990 --> 00:02:34,280
at the last one that I added, which will be test case

50
00:02:34,280 --> 00:02:37,190
number five, I just need to specify that it will go through state

51
00:02:37,190 --> 00:02:41,090
zero, which is this one, five, which is this one, six, and

52
00:02:41,090 --> 00:02:43,130
then back to zero. And I can do the same for the other

53
00:02:43,130 --> 00:02:46,500
test cases. So this will be my complete set of test cases.

54
00:02:46,500 --> 00:02:50,060
So the bottom line here is that it is much harder to build

55
00:02:50,060 --> 00:02:53,080
a set of test cases that will cover the behavior of an informal

56
00:02:53,080 --> 00:02:56,970
description. But by going through a model, so by building in this case,

57
00:02:56,970 --> 00:03:01,700
a finite state machine for that description, we can, in a much easier way, see

58
00:03:01,700 --> 00:03:04,100
what the behaviors of interest of the system

59
00:03:04,100 --> 00:03:05,960
are, and try to cover them. And there

60
00:03:05,960 --> 00:03:07,400
is again in the spirit of breaking

61
00:03:07,400 --> 00:03:09,950
down a complex problem into smaller steps that

62
00:03:09,950 --> 00:03:11,620
we can better manage, which in the end,

63
00:03:11,620 --> 00:03:14,450
results in a more efficient and effective testing.