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 --- .../8 - Statement Coverage - lang_en_vs4.srt | 291 --------------------- 1 file changed, 291 deletions(-) delete mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt (limited to 'usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt') diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt deleted file mode 100644 index 23cfb0a..0000000 --- a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt +++ /dev/null @@ -1,291 +0,0 @@ -1 -00:00:00,270 --> 00:00:03,080 -Now that we saw this overview of white-box testing, I'd like - -2 -00:00:03,080 --> 00:00:06,270 -to start talking about specific coverage criterion. And I'm going to start - -3 -00:00:06,270 --> 00:00:09,010 -with the first one, which is Statement Coverage. This criterion is - -4 -00:00:09,010 --> 00:00:12,355 -going to be characterized by two aspects, the first one is which - -5 -00:00:12,355 --> 00:00:15,580 -are the Test requirements for the criteria and the second one - -6 -00:00:15,580 --> 00:00:18,830 -is how we measure Coverage for that criteria. In the case - -7 -00:00:18,830 --> 00:00:22,200 -of statement coverage, these test requirements are all the statements in - -8 -00:00:22,200 --> 00:00:25,804 -the program. So this is the basic, the first the, the simplest - -9 -00:00:25,804 --> 00:00:29,860 -coverage criteria in the white-box arena. Let me remind you the assumption - -10 -00:00:29,860 --> 00:00:33,280 -that we made at the beginning. White-box testing is based on the assumption - -11 -00:00:33,280 --> 00:00:35,990 -that if there isn't a faulty element in the code, we need - -12 -00:00:35,990 --> 00:00:38,390 -to exercise it. We need to execute it, in order to find the - -13 -00:00:38,390 --> 00:00:41,260 -fault. And that's exactly what statement coverage does. If there is a - -14 -00:00:41,260 --> 00:00:44,450 -statement that is faulty in the code, we need to exercise it, in - -15 -00:00:44,450 --> 00:00:47,490 -order to find the fault. And therefore, a good measure of how well - -16 -00:00:47,490 --> 00:00:51,480 -we exercise the code, is the ratio of the number of executed statements. - -17 -00:00:51,480 --> 00:00:54,950 -So all the statements that my test cases executed, to the total - -18 -00:00:54,950 --> 00:00:58,570 -number of statements in the program. The higher this number, the better - -19 -00:00:58,570 --> 00:01:01,870 -I exercise my code. And we can also look at coverage criterion - -20 -00:01:01,870 --> 00:01:04,290 -in terms of questions. So what is the questions they were trying - -21 -00:01:04,290 --> 00:01:06,940 -to answer when we look at a specific set of test cases - -22 -00:01:06,940 --> 00:01:09,870 -and we assess the statement coverage that they achieved. And the question - -23 -00:01:09,870 --> 00:01:13,440 -is whether each statement in the program has been executed. So, statement - -24 -00:01:13,440 --> 00:01:16,920 -coverage is satisfied when all the statements in the program have been executed. - -25 -00:01:16,920 --> 00:01:19,640 -And we can satisfy to different degrees and the degrees to which it's - -26 -00:01:19,640 --> 00:01:23,320 -satisfied is measured by this value. So now let's go ahead and measure - -27 -00:01:23,320 --> 00:01:27,250 -statement coverage on our printSum example. What I'm going to show down here is - -28 -00:01:27,250 --> 00:01:30,500 -this progress bar in which we show the amount of coverage, the percentage of - -29 -00:01:30,500 --> 00:01:33,060 -coverage achieved. So what this means is that the, if I get to - -30 -00:01:33,060 --> 00:01:36,680 -this point I've covered 25% of the statements in the code. And my goal - -31 -00:01:36,680 --> 00:01:39,160 -is to get up here to cover all the statements in the code. - -32 -00:01:39,160 --> 00:01:42,000 -We have two test cases for this code. The first one that we just - -33 -00:01:42,000 --> 00:01:45,700 -saw, consists of the inputs a equal to 3 and b equal - -34 -00:01:45,700 --> 00:01:48,200 -to 9, and the second one has the inputs a is equal to - -35 -00:01:48,200 --> 00:01:50,840 -minus 5 and b is equal to minus 8. So now let's see - -36 -00:01:50,840 --> 00:01:53,450 -what happens when we run this test case. When we run this test - -37 -00:01:53,450 --> 00:01:56,920 -case, I'm going to show you by highlighting in the code the parts that - -38 -00:01:56,920 --> 00:02:00,430 -we cover when we start executing the code. We cover the first statement, - -39 -00:02:00,430 --> 00:02:01,910 -then we always execute the second - -40 -00:02:01,910 --> 00:02:04,180 -statement, which computes the result, we continue - -41 -00:02:04,180 --> 00:02:07,070 -the execution, we get to the if statement. If the result is greater - -42 -00:02:07,070 --> 00:02:10,038 -than zero, in this case our result is 12 because we - -43 -00:02:10,038 --> 00:02:12,360 -are working with the inputs 3 and 9, and therefore we - -44 -00:02:12,360 --> 00:02:15,710 -execute the true part of the if, we execute the statement. - -45 -00:02:15,710 --> 00:02:18,850 -And at this point, we just jump to the end. Because we - -46 -00:02:18,850 --> 00:02:21,530 -do not execute the else part of the statement, since we - -47 -00:02:21,530 --> 00:02:24,240 -have executed a true one, and therefore, we cover this final - -48 -00:02:24,240 --> 00:02:27,534 -statement. So at the end of the execution of this test - -49 -00:02:27,534 --> 00:02:32,313 -case, we cover one, two, three, four, five statement out of seven - -50 -00:02:32,313 --> 00:02:36,299 -which is roughly speaking 71%. So we can mark in here - -51 -00:02:36,299 --> 00:02:39,779 -that we more or less got to 71% of coverage for - -52 -00:02:39,779 --> 00:02:42,719 -this code. Now let's look at what happens when we execute - -53 -00:02:42,719 --> 00:02:45,700 -test case number two. In this case again, we execute the - -54 -00:02:45,700 --> 00:02:48,660 -first statement, the second statement, the third statement. In this case - -55 -00:02:48,660 --> 00:02:52,010 -though, the first statement, when it evaluates the value of result, - -56 -00:02:52,010 --> 00:02:54,250 -it sees that the result is not greater than zero because - -57 -00:02:54,250 --> 00:02:57,590 -our inputs are minus five and minus eight. Therefore, you will execute - -58 -00:02:57,590 --> 00:03:00,090 -line number five. And because the result is less than - -59 -00:03:00,090 --> 00:03:02,810 -zero, you will also execute line number six. So, at - -60 -00:03:02,810 --> 00:03:05,230 -this point, all of the statements in our code are - -61 -00:03:05,230 --> 00:03:09,360 -executed and therefore, we achieved a 100% statement coverage, which - -62 -00:03:09,360 --> 00:03:13,090 -was our goal. Before looking at other kinds of coverage, - -63 -00:03:13,090 --> 00:03:16,060 -let's see how our statement coverage is used in practice. - -64 -00:03:16,060 --> 00:03:19,170 -First of all, statement coverage is the most used kind - -65 -00:03:19,170 --> 00:03:22,830 -of coverage criterion in industry. Normally for company that uses - -66 -00:03:22,830 --> 00:03:27,200 -statement coverage, the typical coverage target is 80-90%, which - -67 -00:03:27,200 --> 00:03:29,690 -mean the outcome of the test should be such - -68 -00:03:29,690 --> 00:03:32,770 -that 80-90% of the statements are exercised at the - -69 -00:03:32,770 --> 00:03:34,880 -end of testing. So at this point, you might - -70 -00:03:34,880 --> 00:03:36,850 -be wondering, why don't we just shoot for 100%? - -71 -00:03:36,850 --> 00:03:38,580 -Why don't we try to cover all of the - -72 -00:03:38,580 --> 00:03:40,050 -code? We just saw that we could do it. - -73 -00:03:40,050 --> 00:03:41,730 -And so I'm going to ask you the same question. -- cgit 1.4.1