From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 24 May 2020 16:34:31 +0700 Subject: [usth/ICT2.7] Engineer software --- .../8 - Statement Coverage - lang_en_vs4.srt | 291 +++++++++++++++++++++ 1 file changed, 291 insertions(+) create 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 new file mode 100644 index 0000000..23cfb0a --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt @@ -0,0 +1,291 @@ +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