1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
1
00:00:00,110 --> 00:00:02,570
So let me use a slightly expanded version of this
2
00:00:02,570 --> 00:00:05,560
grid. Although we're indeed looking at a needle in a haystack.
3
00:00:05,560 --> 00:00:09,560
And failing inputs are generally sparse, very sparse, in the input
4
00:00:09,560 --> 00:00:12,890
domain. However, they tend to be dense in some parts of
5
00:00:12,890 --> 00:00:15,860
the domain. Like here or here. So how can we leverage
6
00:00:15,860 --> 00:00:18,920
this? The fact that the failures are dense in some subdomains?
7
00:00:18,920 --> 00:00:22,290
As it turns out, the domain is naturally split into partitions.
8
00:00:22,290 --> 00:00:25,340
Where partitions are areas of the domain that are treated homogeneously
9
00:00:25,340 --> 00:00:28,070
by the software. And this is what happens, that normally,
10
00:00:28,070 --> 00:00:31,020
failures tend to be dense in this partitions. So the way
11
00:00:31,020 --> 00:00:34,000
to leverage this characteristic of failures, is that we don't know
12
00:00:34,000 --> 00:00:36,950
want to pick inputs randomly, in the input domain. Just here
13
00:00:36,950 --> 00:00:39,460
and there. Rather we want to do two things. First we
14
00:00:39,460 --> 00:00:43,300
want to identify partitions of our domain. And second we want
15
00:00:43,300 --> 00:00:46,950
to select inputs from each partition. And by doing so, we
16
00:00:46,950 --> 00:00:50,300
can dramatically increase our chances to reveal faults in the code.
17
00:00:50,300 --> 00:00:54,170
So the name that is normally used for this process, is partition testing.
|
