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

+00:00:00,100 --> 00:00:03,060

+There are some important considerations I want to make on final state

+

+2

+00:00:03,060 --> 00:00:06,410

+machines. And more in general, on model based testing. The first one

+

+3

+00:00:06,410 --> 00:00:10,600

+is about applicability. Testing based on final state machines is a very

+

+4

+00:00:10,600 --> 00:00:13,890

+general approach, that we can apply in a number of contexts. And in

+

+5

+00:00:13,890 --> 00:00:16,510

+particular, if you are working with UML, you have state machines for

+

+6

+00:00:16,510 --> 00:00:19,720

+free. Because state charts are nothing else but a special kind of

+

+7

+00:00:19,720 --> 00:00:22,210

+state machine. So you can apply the technique that we just saw

+

+8

+00:00:22,210 --> 00:00:26,010

+directly on state charts, and try to cover their states and their transitions.

+

+9

+00:00:26,010 --> 00:00:29,980

+Another important point is that abstraction is key. You have to find the

+

+10

+00:00:29,980 --> 00:00:33,280

+right level of abstraction. The bigger the system, the more you have to

+

+11

+00:00:33,280 --> 00:00:36,130

+abstract if you want to represent it with a model, and in particular, with

+

+12

+00:00:36,130 --> 00:00:38,710

+the final state machine. So it's like having a slider, and you have

+

+13

+00:00:38,710 --> 00:00:41,840

+to decide where you want to move on that slider. The more you represent,

+

+14

+00:00:41,840 --> 00:00:44,700

+the more complex your system is going to be and the more thorough your

+

+15

+00:00:44,700 --> 00:00:48,110

+testing is going to be but also more expensive. The less you represent the

+

+16

+00:00:48,110 --> 00:00:51,330

+less expensive testing is going to be, but also testing might not be as

+

+17

+00:00:51,330 --> 00:00:53,500

+thorough as it would be otherwise. So you have to find

+

+18

+00:00:53,500 --> 00:00:56,150

+the right balance between abstracting the weight too much and abstracting

+

+19

+00:00:56,150 --> 00:00:59,840

+the weight too little. And finally there are many other approaches.

+

+20

+00:00:59,840 --> 00:01:02,840

+So we just scratched the surface, and we just saw one possible

+

+21

+00:01:02,840 --> 00:01:05,760

+approach. But for instance, other models that you can use are

+

+22

+00:01:05,760 --> 00:01:09,780

+decision tables, flow graphs and even historical models. Models that can

+

+23

+00:01:09,780 --> 00:01:13,560

+guide your testing based on problems that occurred in your system

+

+24

+00:01:13,560 --> 00:01:16,500

+in the past. And also, in this case, I'm going to put pointers

+

+25

+00:01:16,500 --> 00:01:18,460

+to additional materials in the class notes.