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