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
|
1
00:00:00,500 --> 00:00:03,185
To give you a slightly better understanding of the differences
2
00:00:03,185 --> 00:00:06,300
between black-box testing and white-box testing, I am going to provide you
3
00:00:06,300 --> 00:00:10,040
a couple of simple examples that illustrate the, the strengths and
4
00:00:10,040 --> 00:00:12,920
limitations of these two techniques. So, in this case, let's start
5
00:00:12,920 --> 00:00:15,750
with black-box testing, so we're only working with this specification.
6
00:00:15,750 --> 00:00:18,540
So, let's say that our specification says that this is a
7
00:00:18,540 --> 00:00:23,550
program that inputs an integer value and prints it. And implementation,
8
00:00:23,550 --> 00:00:25,900
we don't know because we're working at the black box level.
9
00:00:25,900 --> 00:00:28,710
If we wanted to test this function according to its
10
00:00:28,710 --> 00:00:32,060
specification, what we will probably do is to select a positive
11
00:00:32,060 --> 00:00:35,370
integer, a negative integer, and the zero as test inputs
12
00:00:35,370 --> 00:00:37,840
and see how the program behaves for these inputs. So let
13
00:00:37,840 --> 00:00:41,500
me now show you a possible implementation for this specification.
14
00:00:41,500 --> 00:00:44,590
What I'm showing here is this function that we called print
15
00:00:44,590 --> 00:00:48,010
NumBytes, which takes the parameter and prints it. And one thing
16
00:00:48,010 --> 00:00:50,905
that we notice right away is that, although in the specification,
17
00:00:50,905 --> 00:00:53,960
numbers that are less than 1024 and numbers that
18
00:00:53,960 --> 00:00:57,320
are greater or equal to 1024 are exactly equivalent from
19
00:00:57,320 --> 00:01:01,020
the specification standpoint. They're however treated differently in the
20
00:01:01,020 --> 00:01:04,140
code, so the developer decided that the program was just
21
00:01:04,140 --> 00:01:06,200
going to print the value of the parameter if it's
22
00:01:06,200 --> 00:01:09,300
less than 1024. But it was actually divided by 1024
23
00:01:09,300 --> 00:01:13,560
and printing it with a kilobyte mark after it
24
00:01:13,560 --> 00:01:16,170
if you are greater than 1024. And notice that here,
25
00:01:16,170 --> 00:01:19,370
there is a problem. The developer, just a number 124, instead
26
00:01:19,370 --> 00:01:22,840
of 1024. So there's probably a typo in this point in the
27
00:01:22,840 --> 00:01:26,260
code. So this is a case in which by simply doing black-box
28
00:01:26,260 --> 00:01:28,750
testing, so by simply looking at the specific issue, we might miss
29
00:01:28,750 --> 00:01:31,510
this problem. Because we have no reason to consider numbers that are
30
00:01:31,510 --> 00:01:34,780
less than 1024 or greater than 1024. However if we were to
31
00:01:34,780 --> 00:01:38,010
look at the code, so operating at white-box manner, we will right
32
00:01:38,010 --> 00:01:41,340
away see that we need to have a test case that checks
33
00:01:41,340 --> 00:01:44,880
the program when the parameter is greater than 1024. And we will find
34
00:01:44,880 --> 00:01:47,300
the problem right away. So now let me show you a dual example.
|
