From 8a7dfa0972c83fd811a4296e7373574bea4a28d0 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 19 Jul 2020 20:34:40 +0700 Subject: [usth/ICT2.7] Remove Udacity transcribes --- ...ving Test Case Specifications - lang_en_vs4.srt | 199 --------------------- 1 file changed, 199 deletions(-) delete mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt (limited to 'usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt') diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt deleted file mode 100644 index 5164f1a..0000000 --- a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt +++ /dev/null @@ -1,199 +0,0 @@ -1 -00:00:00,140 --> 00:00:02,790 -Now, let's go back to our systematic functional testing - -2 -00:00:02,790 --> 00:00:05,540 -approach and all the steps in this process. So - -3 -00:00:05,540 --> 00:00:07,680 -far we've seen the first step and the second - -4 -00:00:07,680 --> 00:00:10,340 -step. Now we're going to look at this step in which, - -5 -00:00:10,340 --> 00:00:13,290 -once we have identified the values of interest, we - -6 -00:00:13,290 --> 00:00:18,110 -derive test case specifications for these values, or using these - -7 -00:00:18,110 --> 00:00:21,300 -values. And the test case specification defines how the - -8 -00:00:21,300 --> 00:00:25,230 -values should be put together when actually testing the system. - -9 -00:00:25,230 --> 00:00:29,110 -And test case specification describe how these values should be put - -10 -00:00:29,110 --> 00:00:32,360 -together when testing the system. So let me go back one more - -11 -00:00:32,360 --> 00:00:34,780 -time to our split program, so that we can use the - -12 -00:00:34,780 --> 00:00:37,450 -information that we already computed. At this point what we have is - -13 -00:00:37,450 --> 00:00:41,670 -some possible inputs for "string," our first parameter, and for "size," - -14 -00:00:41,670 --> 00:00:44,410 -our second parameter. And we want to put them together, to generate - -15 -00:00:44,410 --> 00:00:47,080 -the description of what the test case should be. So let - -16 -00:00:47,080 --> 00:00:50,420 -me once more rearrange this a little bit. I first remove the - -17 -00:00:50,420 --> 00:00:53,360 -description of the subdomains, because we won't use them in this step. - -18 -00:00:53,360 --> 00:00:55,800 -And I moved out the set of all our possible inputs, that we're - -19 -00:00:55,800 --> 00:00:59,470 -going to combine to create the test case specification. And one possible way - -20 -00:00:59,470 --> 00:01:03,320 -of doing that is simply to combine the values for the first parameter, - -21 -00:01:03,320 --> 00:01:06,370 -and the values for the second parameter. So the Cartesian product. So - -22 -00:01:06,370 --> 00:01:09,060 -if we do that, what we will obtain is, for example, if we - -23 -00:01:09,060 --> 00:01:12,470 -consider the first possible input, size is equal to minus 1, we can - -24 -00:01:12,470 --> 00:01:15,510 -combine it with these two possible inputs for string, and we will get - -25 -00:01:15,510 --> 00:01:18,680 -size is equal to minus 1 string with length minus 2, or - -26 -00:01:18,680 --> 00:01:21,680 -size is equal to minus 1 string with length minus 1. And we'll - -27 -00:01:21,680 --> 00:01:24,200 -go back in a second to see what this means. Now if we - -28 -00:01:24,200 --> 00:01:27,510 -consider the second possible value for size, size is equal to one, we - -29 -00:01:27,510 --> 00:01:30,260 -also have two cases so the first one in this case that will - -30 -00:01:30,260 --> 00:01:34,030 -be considered a string with length zero. So the antistring. And we can - -31 -00:01:34,030 --> 00:01:37,410 -continue combining this value, but one thing I want to point out is - -32 -00:01:37,410 --> 00:01:40,570 -that if we just go in this straight forward and brute force sort - -33 -00:01:40,570 --> 00:01:43,390 -of way, we will obtain many combinations that don't make any sense, - -34 -00:01:43,390 --> 00:01:46,500 -like for example, this combination which doesn't make any sense because we can - -35 -00:01:46,500 --> 00:01:50,410 -not create the string with length minus 2. Similar for this combination, because - -36 -00:01:50,410 --> 00:01:53,190 -then by the same token, we cannot raise things with length minus 1. - -37 -00:01:53,190 --> 00:01:55,730 -And so there's a lot of cases that we will have to eliminate - -38 -00:01:55,730 --> 00:01:59,380 -afterwards. So what we're going to see in a few minutes is a possible - -39 -00:01:59,380 --> 00:02:02,970 -way in which we can avoid producing these meaningless cases. And at the - -40 -00:02:02,970 --> 00:02:06,380 -same time, keep under control, the number of test cases that we generate. - -41 -00:02:06,380 --> 00:02:09,070 -So lets go back for the last time to our steps - -42 -00:02:09,070 --> 00:02:11,980 -for systematic functional testing. What we just did was to derive - -43 -00:02:11,980 --> 00:02:15,040 -test case specification from a set of relevant inputs. The following - -44 -00:02:15,040 --> 00:02:18,420 -step is to use these test case specifications to generate actual test - -45 -00:02:18,420 --> 00:02:21,170 -cases. And this is normally a fairly mechanical step in the - -46 -00:02:21,170 --> 00:02:23,900 -sense that we just have to instantiate what is in the test - -47 -00:02:23,900 --> 00:02:27,970 -case specification as actual test cases. And it's really dependent on - -48 -00:02:27,970 --> 00:02:32,300 -the specific type of partitions and values identified on the specific context. - -49 -00:02:32,300 --> 00:02:35,100 -So instead of looking at that here in the, in the abstract, - -50 -00:02:35,100 --> 00:02:37,480 -I'm going to show you with an example later on, in the lesson. -- cgit 1.4.1