From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 24 May 2020 16:34:31 +0700 Subject: [usth/ICT2.7] Engineer software --- ...Finite State Machines Example - lang_en_vs4.srt | 251 +++++++++++++++++++++ 1 file changed, 251 insertions(+) create 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 new file mode 100644 index 0000000..f889057 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt @@ -0,0 +1,251 @@ +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