about summary refs log tree commit diff
path: root/usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt
diff options
context:
space:
mode:
Diffstat (limited to 'usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt')
-rw-r--r--usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt191
1 files changed, 191 insertions, 0 deletions
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.