From 8a7dfa0972c83fd811a4296e7373574bea4a28d0 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 19 Jul 2020 20:34:40 +0700 Subject: [usth/ICT2.7] Remove Udacity transcribes --- ...Finite State Machines Example - lang_en_vs4.srt | 251 --------------------- 1 file changed, 251 deletions(-) delete mode 100644 usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt (limited to 'usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt') 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. -- cgit 1.4.1