Create data
A Test Data Library is used to store or define the way to retrieve the data that will be necessary to perform the tests. Different way of getting the data can be used (INTERNAL, SQL, SERVICE or CSV) but that definition is independent from the test case definition so that you can easily change from one to another without impacting all the corresponding test cases.
The first sub-data does not require a name, it correspond to the key of the datalib and should be unique to that entry. Inside a testcase, if property PROP1 is defined as getFromTestDataLib on that data, that sub data is retreived as %PROP1%. The other sub data values are retreived as %PROP1.SUBDATA1%.
If you do not select an environment, a system and a country, your data will be available for all environments, systems and countries.
Cerberus allows the definition of 4 types : INTERNAL, SQL, CSV and SERVICE
TYPE |
Description |
INTERNAL |
Static test data - in each execution the values used by the test cases are statically definied directly in Cerberus. |
SQL |
Test data obtained from a SQL execution – values depend on what the SQL return on the corresponding environment. |
CSV |
Test data obtained from a CSV file structure privided by a URL. Values depend on the result of the service call to CSV file. |
SERVICE |
Test data obtained from a SERVICE call – values depend on the result of the service call. Service needs to be configured on Service screen inside application menu. |
Data configurations
INTERNAL configuration
This is used to store the test data directly inside Cerberus. This is considered as being static as it will require to define manually each data inside Cerberus. No specific configuration needed, just feed static sub data values in subdata tab.
NOTE : You can define as many INTERNAL data lib entry as you want be giving them the same name. That way, Cerberus will be able to pick one of them from that list (just like it would for the dynamic type such as SQL, SRVICE or CSV).
SQL configuration
This is used to retrieve the test data in a dynamic way from any database that has JDCB driver available (it still require Glassfish configuration to create the corresponding connection pool). The SQL will be performed during the test execution to get the data in the right environment at the right timing..
Field |
Description |
Database |
Database where the script attribute should be executed. |
Script |
SQL Script you want to execute. |
All Subdata now need to be defined in Column with the name of the column where the subdata is defined.
SERVICE configuration
Just like SQL, it will get the data in a dynamic way but from a service call in stead of an SQL. The best option is to define a corresponding service (Service) and point to it (it can then be REST (both GET or POST) or SOAP).
But you can also directly define a Service call request (Service Path, Method and Envelope) if it is in a SOAP format.
Field |
Description |
Database |
Database where the Service Path will be requested. (optional) |
Service |
Name of the service that define the request. |
Service Path |
Location of the service. Example: http://mydomain/mywebservicelocationmywebservicelocation |
Method |
Method that is invoked by the SOAP request/call. |
Envelope |
Envelope that is sent in the SOAP request. |
All Subdata now need to be defined in Parsing Answer with the xpath or jsonpath where the subdata is defined.
CSV configuration
Just like SQL and SERVICE, it will get the data in a dynamic way but from a csv flat file (that can be static or dynamic). Just define the path to the csv file and separator used.
Field |
Description |
Database |
Name of the database the define the root path where to get the CSV file. (optional) |
CSV URL |
CSV URL specifies the URL where the CSV can be reached. Can be a full URL but also a relative URL in case the Database information is provided and configured at environment level. |
Separator |
Separator used parsing a CSV. |
All Subdata now need to be defined in Column Position with an integer that define the number of the column where the subdata is defined.
Database field configuration
Database can be configured for data library of types : SQL, SERVICE and CSV. It is used in order to make the access to the data linked to the environment so that, a testcase executed in PROD environment will not call the same URL (or access the same JDBC ressource) as in UAT.
In that example, CRB database has been defined and as a consequence, CSV URL has been modified to be relative.
Databases can be created inside invariant screen. Use PROPERTYDATABASE idname.
Once the database is created in invariant table and used inside the test data library, you can define the context of the data access calls for each environment (System + Country + Environment) inside the Environment screen for the 3 types of datasource :
-
For SQL Test Data Library -→ JDBC Ressource : Connection pool name to be configured inside Glassfish application server.
-
For SERVICE Test Data Library -→ SOAP Service URL : Left part of the URL that will be used to call the Service URL
-
For CSV Test Data Library -→ CSV Service URL : Left part of the URL that will be used to get the CSV file.
