1 files changed, 135 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt
new file mode 100644
index 0000000..dab72eb
--- /dev/null
+++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt
@@ -0,0 +1,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.