The below diagram illustrates the major components of the automated system design. Below it is a brief explanation of each part:
Figure 1 - System Layers (abstraction)
Test Execution LayerThis is the only layer that faces the user (i.e. the test script programmer). From here we make calls to the methods / services exposed by the functional layer. For example: create_report, load_data. Pass / Fail status is determined at this layer (based on 1 or 0 returned from functional layer).
Functional LayerThis is the ONLY layer that speaks AUT language and, as such, drives the AUT. It makes calls to the System Layer as needed to access services like the DB, capture screenshots, write to log files, etc.
All actions and functions that we need to perform on the AUT (application under test) are defined here and made available to the test execution layer. All functions should return 1 when successful or 0 when unsuccessful.
System I/F LayerThe System Layer is responsible for interfacing with any other component that is not the AUT. It should provide services for db access, reading and writing. Log file creation and parsing. Test results processing and QC integration (post test run).
Keyword Testing FrameworkUsing the keywords approach the separation / abstraction of layers will be supported by having two sets of keywords. Both sets of keywords are exposed as methods in a Perl library file and are:
Functional keywords: These keywords interact with the AUT and define the actions to be followed when the keyword is invoked.
System keywords: Interface with the system and provide services to db access, log files, copying and moving files, launching the application, etc.
Keywords System Diagram
As shown above, the system includes 4 major parts:
- keyword / actions definitions (actions.pl)
- data files (keywords+arguments), can be .tsv, .csv, .xls (keywords.csv)
- test case file (test.pl)
- driver (driver.pl)
Data files in the form of tsv, csv or xls contain “keyword” and “argument” data separated by a tab, comma, etc depending on file format used.
The keywords are the method names used in the function definition. For example, start_application keyword is mapped to start_application Perl sub. The “arguments” in the data file are the functions parameters. They are like passed in parameters, being provided by the keyword data file.
Before the keywords with arguments included in the keywords data file can be executed (called upon) they must be turned into the scripting language specific format. This is the job of the driver.pl file. It parses the data file constructing the method name as it goes and then eventually executing the function call using, in our case, Perl eval function.
The function call defined in the action class is now called upon with the arguments in the data file passed in. The actions are executed on the AUT and success or failure is reported back as 1 or 0 respectively.
Contact us if you'd like to hear more or if you'd like to hire us to provide a similar service.