about summary refs log tree commit diff
path: root/usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt
diff options
context:
space:
mode:
Diffstat (limited to 'usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt')
-rw-r--r--usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt171
1 files changed, 171 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt
new file mode 100644
index 0000000..b1a38a7
--- /dev/null
+++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt
@@ -0,0 +1,171 @@
+1

+00:00:00,320 --> 00:00:04,059

+So let's start our lesson on white docs testing by considering again the

+

+2

+00:00:04,059 --> 00:00:07,470

+program PrintSum. If you remember, this is the same program that we used when

+

+3

+00:00:07,470 --> 00:00:10,300

+we were talking about black box testing. It's the program that takes two

+

+4

+00:00:10,300 --> 00:00:14,050

+integers, A and B, and produces, as a result, the sum of the two.

+

+5

+00:00:14,050 --> 00:00:16,570

+And when we were looking at this problem in the context of black

+

+6

+00:00:16,570 --> 00:00:17,760

+box testing, we did not look at

+

+7

+00:00:17,760 --> 00:00:19,700

+implementation. But that's exactly what we're going to

+

+8

+00:00:19,700 --> 00:00:22,090

+do now. So we're going to open the box and look at how the

+

+9

+00:00:22,090 --> 00:00:25,700

+code is implemented. And as you can see, the programmer was kind of creative.

+

+10

+00:00:25,700 --> 00:00:28,670

+Because instead of just adding the two numbers and printing them, he

+

+11

+00:00:28,670 --> 00:00:32,080

+or she also decided to print them in a specific color depending

+

+12

+00:00:32,080 --> 00:00:36,840

+on whether they were positive numbers or negative numbers. So positive results

+

+13

+00:00:36,840 --> 00:00:40,040

+are printed in red and negative results are printed in blue. And as

+

+14

+00:00:40,040 --> 00:00:41,970

+you can see by looking at the code we can see some

+

+15

+00:00:41,970 --> 00:00:45,150

+interesting cases that we might want to test. For instance you can

+

+16

+00:00:45,150 --> 00:00:48,190

+see that there are two decisions made here. So we might decide

+

+17

+00:00:48,190 --> 00:00:51,100

+that this is an interesting case and therefore we want to test it.

+

+18

+00:00:51,100 --> 00:00:53,770

+Similarly we might look at this other case and we might

+

+19

+00:00:53,770 --> 00:00:56,465

+also decide that this is another interesting case and therefore we

+

+20

+00:00:56,465 --> 00:00:58,970

+want to test this one as well. So let's discuss this

+

+21

+00:00:58,970 --> 00:01:01,480

+in a slightly more formal way by introducing the concept of

+

+22

+00:01:01,480 --> 00:01:05,110

+coverage criteria which are really the essence of why box testing.

+

+23

+00:01:05,110 --> 00:01:08,930

+First of all coverage criteria are defined in terms of test

+

+24

+00:01:08,930 --> 00:01:13,460

+requirements where test requirements are the elements, the entities in the

+

+25

+00:01:13,460 --> 00:01:16,250

+code that we need to exercise. That we need to execute

+

+26

+00:01:16,250 --> 00:01:18,690

+in order to satisfy the criteria. And we'll see plenty

+

+27

+00:01:18,690 --> 00:01:21,430

+of examples of that. And normally, when I apply a coverage

+

+28

+00:01:21,430 --> 00:01:24,810

+criterion, my result is a set of test specifications. And we

+

+29

+00:01:24,810 --> 00:01:26,540

+already saw test specifications. Those

+

+30

+00:01:26,540 --> 00:01:29,540

+are basically descriptions, specifications, of how

+

+31

+00:01:29,540 --> 00:01:32,786

+the tests should be in order to satisfy the requirements. And

+

+32

+00:01:32,786 --> 00:01:36,210

+they also result in actual test cases, which are instantiations of

+

+33

+00:01:36,210 --> 00:01:39,470

+the test specifications. And again this is exactly analogous to what

+

+34

+00:01:39,470 --> 00:01:41,830

+we saw when we were talking about the black box testing.

+

+35

+00:01:41,830 --> 00:01:43,960

+So let's see what this means by going back to our

+

+36

+00:01:43,960 --> 00:01:46,680

+example. A minute ago, we looked at the print sum code

+

+37

+00:01:46,680 --> 00:01:50,000

+and we identified two interesting cases for our code. And those

+

+38

+00:01:50,000 --> 00:01:53,430

+are exactly our test requirements. So we have a first test

+

+39

+00:01:53,430 --> 00:01:57,840

+requirement here, which is the execution of this particular statement and

+

+40

+00:01:57,840 --> 00:02:01,500

+a second requirement here and this one corresponds to the execution

+

+41

+00:02:01,500 --> 00:02:04,580

+of this other statement. So for this example there are two

+

+42

+00:02:04,580 --> 00:02:06,920

+things that we need to do in order to satisfy our

+

+43

+00:02:06,920 --> 00:02:10,100

+coverage requirements. Execute this statement and execute this statement.