diff options
author | Nguyễn Gia Phong <mcsinyx@disroot.org> | 2020-05-24 16:34:31 +0700 |
---|---|---|
committer | Nguyễn Gia Phong <mcsinyx@disroot.org> | 2020-05-24 16:34:31 +0700 |
commit | b2d80610db6beda38573890ed169815e495bc663 (patch) | |
tree | 176e1bca6fe644c619d53cf1c24682c244b79cf6 /usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt | |
parent | 49376ab97c7427f1c1eca64072d1a934c2e52f50 (diff) | |
download | cp-b2d80610db6beda38573890ed169815e495bc663.tar.gz |
[usth/ICT2.7] Engineer software
Diffstat (limited to 'usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt')
-rw-r--r-- | usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt | 179 |
1 files changed, 179 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt new file mode 100644 index 0000000..75da7e8 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt @@ -0,0 +1,179 @@ +1 +00:00:00,140 --> 00:00:02,690 +So what is the starting point of black box testing? Black + +2 +00:00:02,690 --> 00:00:06,010 +box testing start from a description of the software or as we + +3 +00:00:06,010 --> 00:00:09,590 +call it, a functional specification. And the final result of black + +4 +00:00:09,590 --> 00:00:12,760 +box testing is a set of test cases, a set of actual + +5 +00:00:12,760 --> 00:00:16,410 +inputs and corresponding outputs that we can use to exercise our + +6 +00:00:16,410 --> 00:00:19,030 +code and to try to find defects in our code. So the + +7 +00:00:19,030 --> 00:00:22,060 +question is, how do we get from functional specification to test + +8 +00:00:22,060 --> 00:00:25,510 +cases? Doing these derivations, so going from this description to a concrete + +9 +00:00:25,510 --> 00:00:28,550 +set of tests, is a very complex analytical process. + +10 +00:00:28,550 --> 00:00:31,220 +And normally brute force generation is not a good + +11 +00:00:31,220 --> 00:00:34,430 +idea because it's inefficient and ineffective. What we want + +12 +00:00:34,430 --> 00:00:37,540 +to do instead is to have a systematic approach to + +13 +00:00:37,540 --> 00:00:40,250 +derive test cases from a functional specification. What a + +14 +00:00:40,250 --> 00:00:43,970 +systematic approach does is to simplify the overall problem by + +15 +00:00:43,970 --> 00:00:48,320 +dividing the process into elementary steps. In particular, in + +16 +00:00:48,320 --> 00:00:50,520 +this case, we will perform three main steps. The first + +17 +00:00:50,520 --> 00:00:55,790 +step is to identify independently testable features. Individual features in + +18 +00:00:55,790 --> 00:00:57,600 +the soft hood that we can test. And we're going to + +19 +00:00:57,600 --> 00:00:59,990 +expand on each one of these steps in the next + +20 +00:00:59,990 --> 00:01:02,490 +part of the lesson. The following step is once we have + +21 +00:01:02,490 --> 00:01:06,000 +these independently testable features to identify what are the relevant + +22 +00:01:06,000 --> 00:01:08,590 +inputs. So what are the inputs or the behavior that is + +23 +00:01:08,590 --> 00:01:11,610 +worth testing for these features. Next once we have these + +24 +00:01:11,610 --> 00:01:13,020 +inputs, we're going to derive test + +25 +00:01:13,020 --> 00:01:15,770 +specifications. And test case specifications are + +26 +00:01:15,770 --> 00:01:19,490 +description of the test cases that we can then use + +27 +00:01:19,490 --> 00:01:23,270 +to generate actual test cases. And proceeding in this way, + +28 +00:01:23,270 --> 00:01:26,050 +by this steps, has many advantages. It allows for the + +29 +00:01:26,050 --> 00:01:29,920 +coupling different activities. It allows for dividing brain intensive steps from + +30 +00:01:29,920 --> 00:01:32,240 +steps that can be automated, which is a great advantage. + +31 +00:01:32,240 --> 00:01:34,980 +And also we will see, it allows you for monitoring + +32 +00:01:34,980 --> 00:01:38,040 +the testing process. So to figure out whether your testing + +33 +00:01:38,040 --> 00:01:41,000 +process is going as expected, for example, if you're generating too + +34 +00:01:41,000 --> 00:01:44,160 +many test cases. Or you're generating the number of test cases that your + +35 +00:01:44,160 --> 00:01:47,880 +amount of resources available allows you to run. So let's start by looking + +36 +00:01:47,880 --> 00:01:51,230 +at the first step of this process in which our goal is to + +37 +00:01:51,230 --> 00:01:54,820 +go from a Functional Specification to a set of features that we can + +38 +00:01:54,820 --> 00:01:57,700 +test in the software. So what we want to do is to identify all + +39 +00:01:57,700 --> 00:02:00,290 +of the feature of the software. And why do we want to do this? + +40 +00:02:00,290 --> 00:02:02,650 +Well you know, in the spirit of breaking down the complexity of the + +41 +00:02:02,650 --> 00:02:06,170 +problem, it does not make sense to just try to devise test cases for + +42 +00:02:06,170 --> 00:02:08,750 +all the features of the software at once. For any non-trivial + +43 +00:02:08,750 --> 00:02:11,980 +software, that's a humongous problem, and something that we cannot really + +44 +00:02:11,980 --> 00:02:16,300 +handle effectively. A much better way is to identify independently testable + +45 +00:02:16,300 --> 00:02:19,100 +features and consider one of them at a time when generating tests. |