about summary refs log tree commit diff
path: root/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt
diff options
context:
space:
mode:
Diffstat (limited to 'usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt')
-rw-r--r--usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt251
1 files changed, 0 insertions, 251 deletions
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt
deleted file mode 100644
index f889057..0000000
--- a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt
+++ /dev/null
@@ -1,251 +0,0 @@
-1

-00:00:00,140 --> 00:00:03,010

-In this example, we're going to start from an informal specification, and the

-

-2

-00:00:03,010 --> 00:00:06,670

-specification is the one shown here in file spec.txt. This is the

-

-3

-00:00:06,670 --> 00:00:10,210

-specification for the maintenance function in a specific system. So what we're

-

-4

-00:00:10,210 --> 00:00:13,630

-doing is that we're taking the description of the functionality of a system,

-

-5

-00:00:13,630 --> 00:00:16,219

-and we're building a model, in this case a final state machine

-

-6

-00:00:16,219 --> 00:00:18,710

-for it. And there is no need to look at all the details

-

-7

-00:00:18,710 --> 00:00:21,350

-for this specification, but I want to point out that if you

-

-8

-00:00:21,350 --> 00:00:25,640

-look at the way the specification is written, we can identify specific cases

-

-9

-00:00:25,640 --> 00:00:28,210

-that we need to take into account. Like here if something

-

-10

-00:00:28,210 --> 00:00:31,920

-happens, something else will follow. Again, if something happens something else

-

-11

-00:00:31,920 --> 00:00:35,690

-will follow. So we have multiple choices here. Here will determine

-

-12

-00:00:35,690 --> 00:00:38,140

-the next steps and so on. So all we have to

-

-13

-00:00:38,140 --> 00:00:42,420

-do is to go through this process, identify these cases and

-

-14

-00:00:42,420 --> 00:00:45,300

-then build a machine that represents these cases. For the spec

-

-15

-00:00:45,300 --> 00:00:47,830

-that we just consider this is the state machine that will

-

-16

-00:00:47,830 --> 00:00:50,960

-result. Again there is no need to go through all the details,

-

-17

-00:00:50,960 --> 00:00:53,090

-but what I want to point out is that we have

-

-18

-00:00:53,090 --> 00:00:55,710

-a set of states. So for instance, we have state zero,

-

-19

-00:00:55,710 --> 00:00:58,380

-which is no maintenance, and if a request comes in, the

-

-20

-00:00:58,380 --> 00:01:01,350

-system will move, and the system wait for pickup. Then if

-

-21

-00:01:01,350 --> 00:01:04,400

-the pickup actually occurs, the system will move to the repair

-

-22

-00:01:04,400 --> 00:01:07,540

-state, and so on and so forth. So this is just

-

-23

-00:01:07,540 --> 00:01:13,070

-a more systematic representation of what was in the former specification.

-

-24

-00:01:13,070 --> 00:01:16,160

-And I will argue that this is much easier to understand at

-

-25

-00:01:16,160 --> 00:01:19,170

-least for somebody who has to develop tests for this system. In

-

-26

-00:01:19,170 --> 00:01:21,770

-fact what we're going to see next is how we can go from that

-

-27

-00:01:21,770 --> 00:01:24,790

-representation to a set of test cases. And the way which we do

-

-28

-00:01:24,790 --> 00:01:28,950

-it is by covering the behaviors represented by defining state machine. And we

-

-29

-00:01:28,950 --> 00:01:31,500

-can decide how we want to cover them. For example we might want

-

-30

-00:01:31,500 --> 00:01:35,080

-to cover all the states. So we might want to identify paths in

-

-31

-00:01:35,080 --> 00:01:38,310

-the state machine that go through all the states in the machine. Like

-

-32

-00:01:38,310 --> 00:01:41,840

-the one I just draw or this one, this one and this one.

-

-33

-00:01:41,840 --> 00:01:44,900

-So if we consider these four test cases, we can see that all the

-

-34

-00:01:44,900 --> 00:01:48,470

-states in my system or at least all the states that I have identified

-

-35

-00:01:48,470 --> 00:01:51,450

-are covered. I might want to go a little further, and decide that I

-

-36

-00:01:51,450 --> 00:01:54,210

-don't only want to cover all of the states, but I want to cover, all

-

-37

-00:01:54,210 --> 00:01:57,930

-of the transitions, because, it makes sense to visit a state, when coming from

-

-38

-00:01:57,930 --> 00:02:00,380

-different states. And, if I want to do that, and I look at the

-

-39

-00:02:00,380 --> 00:02:03,440

-test cases that I generated so far, I can see that there is one

-

-40

-00:02:03,440 --> 00:02:06,910

-transition, the one here, that is not covered. And, the same can be said for

-

-41

-00:02:06,910 --> 00:02:09,210

-the two transitions here. So what I can decide to do is

-

-42

-00:02:09,210 --> 00:02:13,370

-to generate another test case, that covers those or extend an existing one.

-

-43

-00:02:13,370 --> 00:02:16,500

-For instance, I could extend this test case by adding a visit to

-

-44

-00:02:16,500 --> 00:02:20,760

-the state, before going back to these two. Alternatively, I could also generate

-

-45

-00:02:20,760 --> 00:02:24,390

-new test cases, such as this one. To cover the missing transitions.

-

-46

-00:02:24,390 --> 00:02:26,350

-And once I have these test cases, I can express them in a

-

-47

-00:02:26,350 --> 00:02:29,860

-clearer way by simply specifying what are the states that they cover. I'm

-

-48

-00:02:29,860 --> 00:02:31,990

-just going to give you a couple of examples. Say, if we look

-

-49

-00:02:31,990 --> 00:02:34,280

-at the last one that I added, which will be test case

-

-50

-00:02:34,280 --> 00:02:37,190

-number five, I just need to specify that it will go through state

-

-51

-00:02:37,190 --> 00:02:41,090

-zero, which is this one, five, which is this one, six, and

-

-52

-00:02:41,090 --> 00:02:43,130

-then back to zero. And I can do the same for the other

-

-53

-00:02:43,130 --> 00:02:46,500

-test cases. So this will be my complete set of test cases.

-

-54

-00:02:46,500 --> 00:02:50,060

-So the bottom line here is that it is much harder to build

-

-55

-00:02:50,060 --> 00:02:53,080

-a set of test cases that will cover the behavior of an informal

-

-56

-00:02:53,080 --> 00:02:56,970

-description. But by going through a model, so by building in this case,

-

-57

-00:02:56,970 --> 00:03:01,700

-a finite state machine for that description, we can, in a much easier way, see

-

-58

-00:03:01,700 --> 00:03:04,100

-what the behaviors of interest of the system

-

-59

-00:03:04,100 --> 00:03:05,960

-are, and try to cover them. And there

-

-60

-00:03:05,960 --> 00:03:07,400

-is again in the spirit of breaking

-

-61

-00:03:07,400 --> 00:03:09,950

-down a complex problem into smaller steps that

-

-62

-00:03:09,950 --> 00:03:11,620

-we can better manage, which in the end,

-

-63

-00:03:11,620 --> 00:03:14,450

-results in a more efficient and effective testing.