Automation Objects contain configuration for each test execution. Automation Objects define the interface under test, test conditions, and necessary data manipulation. Automation Objects can also point to other objects, UI scripts, database validation definitions, and more.
Automation Objects Management
To start working with Automation Objects go to the Fiori launchpad and select the Automation Objects tile.
Automation Objects list will open, with typical list filtering features available.
Elements of Automation Objects list
Automation Obj. - technical name of automation object
Description - user friendly free form description
Type - Type of test case supported by the Automation Object
Interface - Interface name as defined in the Automation Object
Automation Object list features
List filtering
Create new Automation Object
Copy selected Automation Objects
Delete selected Automation Objects
Export selected Automation Objects to file
Import Automation Objects from file
Export Automation Objects lists to spreadsheet file
Working with Automation Objects
Clicking an Automation Object from the list or creating a new one will open Automation Object edition screen.
Automation Object edit screen sections
First items from top are the automation object name, description and assigned test type. Then the screen is divided in several sections. Navigation between these sections is possible by scrolling or clicking the section names.
Basic Information
This section contains the basic information about the integration being tested. Depending on selected test type this section will contain different fields, relating to the specific integration technology - e.g. for SAP IS (CPI) these would be the iFlow name.
Backend Systems
[this is only available in APITester]
Backend Systems allows to specify the system lines for database validation. The specified systems lines are read from the configuration and, together with landscape on which the test case is executed, map to a RFC connection. Int4 Suite uses this RFC connection to execute dedicated function modules and reading data from the system’s database for comparison.
Two system lines need to be specified. The current doc. system line points to the system where we expect to find data from current test execution. The reference document will be read from the system specified by reference doc. system line.
Based on Your testing scenario, both current and reference system lines can be the same or different. For regression testing it will usually be the same system line, e.g. ECC. The testing landscapes are then different, e.g. Test and Production and the system would read reference from Production and current document from Test. For migration scenarios, e.g. ECC to S/4HANA, usually the reference would be ECC and current would be S/4HANA. Please refer to the https://int4support.atlassian.net/wiki/spaces/IUM/pages/2068021270/Int4+APITester#Environments-and-System-lines section for more details on the system lines definition.
Database Validations
[this is only available in APITester]
Database Validation ruleset points to a specific Database Validation object. It’s settings are read and used for execution of the database tables and fields comparison. This allows for single database validation ruleset to be used with multiple Automation Objects.
Read more here on defining the Database Validation rulesets: DB Validation Rulesets
Variables
Payload Validations
Payload Matching
IDoc Status Validations
[this is only available in APITester]