From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001
From: Nguyễn Gia Phong <mcsinyx@disroot.org>
Date: Sun, 24 May 2020 16:34:31 +0700
Subject: [usth/ICT2.7] Engineer software

---
 .../13 - Condition Coverage - lang_en_vs4.srt      | 191 +++++++++++++++++++++
 1 file changed, 191 insertions(+)
 create mode 100644 usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt

(limited to 'usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt')

diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt
new file mode 100644
index 0000000..bba72fc
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt	
@@ -0,0 +1,191 @@
+1
+00:00:00,470 --> 00:00:03,046
+What I'm going to do next is to introduce a few additional
+
+2
+00:00:03,046 --> 00:00:06,350
+coverage criteria using a slightly more complex example, but still a
+
+3
+00:00:06,350 --> 00:00:09,370
+pretty simple one. What I'm showing here is a program that
+
+4
+00:00:09,370 --> 00:00:12,145
+reads two real numbers, x and y. And then, if x
+
+5
+00:00:12,145 --> 00:00:15,148
+is equal to 0 or y is greater than 0, it
+
+6
+00:00:15,148 --> 00:00:19,360
+computes y as y divided by x. Otherwise, it computes x
+
+7
+00:00:19,360 --> 00:00:22,110
+as y plus 2, then it writes the value of x,
+
+8
+00:00:22,110 --> 00:00:25,730
+the value of y, and it terminates. Let's also introduce a CFG
+
+9
+00:00:25,730 --> 00:00:29,160
+for the program. As you can see, the CFG represents the statements
+
+10
+00:00:29,160 --> 00:00:31,900
+in the code and their control flow. And in this case, I made
+
+11
+00:00:31,900 --> 00:00:35,800
+explicit over the branches what are the conditions under which those branches
+
+12
+00:00:35,800 --> 00:00:38,530
+are taken to make it simpler to look at the example. Let's assume
+
+13
+00:00:38,530 --> 00:00:41,280
+that we have two tests for this code that are shown here.
+
+14
+00:00:41,280 --> 00:00:44,286
+For the first one, the inputs are 5 and 5. For the second
+
+15
+00:00:44,286 --> 00:00:47,610
+one, 5 and minus 5. If we consider branch coverage for this code
+
+16
+00:00:47,610 --> 00:00:50,990
+and we consider the two test cases, for the first one this condition
+
+17
+00:00:50,990 --> 00:00:53,440
+is true. Because x is not equal to 0 but y
+
+18
+00:00:53,440 --> 00:00:56,660
+is greater than 0. And therefore, we will follow this tree branch.
+
+19
+00:00:56,660 --> 00:00:59,640
+For the second one, the condition is false. Because x is not
+
+20
+00:00:59,640 --> 00:01:03,200
+equal to 0 and y is not greater than 0. Therefore, the
+
+21
+00:01:03,200 --> 00:01:05,990
+negation of it is true and we will follow this branch. In
+
+22
+00:01:05,990 --> 00:01:09,530
+other words, these two test cases achieve 100% branch coverage on this
+
+23
+00:01:09,530 --> 00:01:12,120
+code. If we look at the code though, we can see that
+
+24
+00:01:12,120 --> 00:01:15,879
+there is the possibility of making this code fail. Consider this statement,
+
+25
+00:01:15,879 --> 00:01:18,147
+if x is equal to 0, we could have a division
+
+26
+00:01:18,147 --> 00:01:21,710
+by 0. However, these two test cases, despite the fact that
+
+27
+00:01:21,710 --> 00:01:25,008
+they achieved 100% branch coverage, will not rebuild this problem. So
+
+28
+00:01:25,008 --> 00:01:27,564
+how can we be more thorough? I'll let you think about it
+
+29
+00:01:27,564 --> 00:01:29,964
+for a second, so think about how can we test more
+
+30
+00:01:29,964 --> 00:01:33,260
+thoroughly, in a more complete way, this code. So, in a way
+
+31
+00:01:33,260 --> 00:01:37,220
+that goes beyond branch coverage. And the answer is that we
+
+32
+00:01:37,220 --> 00:01:41,250
+can make each condition true and false. Instead of just considering the
+
+33
+00:01:41,250 --> 00:01:44,570
+whole predicate here. And that's exactly what is required by
+
+34
+00:01:44,570 --> 00:01:47,480
+the next criteria that we're going to consider which is condition
+
+35
+00:01:47,480 --> 00:01:49,880
+coverage. We're going to define it as usual in terms of
+
+36
+00:01:49,880 --> 00:01:53,070
+test requirements and coverage measure. In this case, the test
+
+37
+00:01:53,070 --> 00:01:57,540
+requirements for condition coverage are the individual conditions in the
+
+38
+00:01:57,540 --> 00:02:00,510
+program. So we want each condition in the program to
+
+39
+00:02:00,510 --> 00:02:03,900
+be both true and false first time execution. So the
+
+40
+00:02:03,900 --> 00:02:06,420
+way in which we can measure that is by measuring the
+
+41
+00:02:06,420 --> 00:02:09,150
+number of conditions that were both true and false
+
+42
+00:02:09,150 --> 00:02:11,580
+when we executed our tests over the total number
+
+43
+00:02:11,580 --> 00:02:14,180
+of conditions. And that gives us the percentage of
+
+44
+00:02:14,180 --> 00:02:17,270
+coverage that we achieved for condition coverage. Again, if you
+
+45
+00:02:17,270 --> 00:02:18,638
+want to look at this criteria in the form
+
+46
+00:02:18,638 --> 00:02:21,245
+of a question. The question would be, has each boolean
+
+47
+00:02:21,245 --> 00:02:25,480
+sub-expression, which means every condition in every predicate, evaluated
+
+48
+00:02:25,480 --> 00:02:28,010
+both to true and false when we run our tests.
-- 
cgit 1.4.1