Skip to content

Input sheet structure

Kannan Ramamoorthy edited this page Mar 29, 2022 · 5 revisions

The input excel should be structured as following worksheets,

  • Base_Config: Contains global configs that are required for the test.

  • Test_Suites: Logical grouping of similar test scenarios.

  • Test_Definitions: Contains the list of Services API definitions for the Rest Application which needs to test.

  • Test_Scenarios: Contains the actual scenarios to be tested. This could make use of one or more APIs defined in the Test_Definitions.

Base_Config:

Base_config sheet, should contain the basic necessary information on the Rest Application which needs to be tested . In the sheets the headers are sectioned in Rows . Each Row first Cell will be a header.

Below Table shows the list of headers, description, format and examples for better understanding.

Header Name Description Type Mandatory/Optional Example

app_name

Give a name to the Rest Application which needs to be Tested.

String

Optional

PetStore Test Application

base_url

The URL of the Rest Application which needs to test, should be in the format <protocol>://<host>:<port>/<base_path>

String

Mandatory

https://myservice.io/v2

default_headers

Default headers which will be added to each of the RestAPI request headers which need to be tested. Should be Json format.

Json

Optional

{"Content-Type":"application/json","Accept":"application/json"

Test_Definitions :

As mentioned earlier, this represents rudimentary APIs that will be called and tested. The columns and the meaning of the columns in the sheet is as below,

Header Name Description Type Mandatory/Optional Example

case_unique_name

Name of the Test Case Definition . Should be unique, duplicate names should not exist.

String

Mandatory

create_use

depends_on

Sometimes other Test_definitions need to be executed before executing the current Test_definition . Includes another case_unique_name which needs to be executed first.

Comma separated strings

optional

get_user,login_user

case_description

Description about the Test_definition

String

optional

API for fetching the information of all users.

request_url

Endpoint of the Rest API

String

Mandatory

/user

request_method

Endpoint Http Method. Should be one of HTTP Methods

String

Mandatory

POST

request_headers

Endpoint Http Request Headers

Json

Optional

{"Content-Type":"application/ json","Accept":"application/json"}

request_query_params

Query parameters for this endpoint

Json

Optional

{"user:"Tom","index":2}

request_body_params

Endpoint Body parameters .Format can be json or String. Provide the appropriate Content-Type in the request_headers .

Json / String

Optional

{"id": 1,"email": "[email protected]","phone": "99999999999"}

request_pre_call_hook

middlewares on request before api call like authentications,etc

Json

optional

{}

request_post_call_hook

middlewares on request after api call like writing response to file,etc

Json

optional

{}

expected_response

The API call response body to be expected, Will evaluate expected response body with the actual api call response body. Should provide the appropriate response content-type in the response headers .

Json/String

Optional

{ "id": 1,"email": "[email protected]","phone": "99999999999"}

expected_response_matcher

Evaluation technique names.Will evaluate the api response body with expected_response body. should be one of the enums [NOOP_MATCHER,EXACT_MATCHER,PARTIAL_MATCHER]

Enum of [NOOP_MATCHER,EXACT_MATCHER,PARTIAL_MATCHER]

Mandatory

EXACT_MATCHER

expected_header

The API call response headers to be expected.Will evaluate expected response header with the actual api call response header.

Json

Optional

{"Content-Type":"application/json","Server":"Jetty"}

expected_header_matcher

Evaluation technique names.Will evaluate the api response header with expected_response header. should be one of the enums [NOOP_MATCHER,EXACT_MATCHER,PARTIAL_MATCHER]

Enum of [NOOP_MATCHER,EXACT_MATCHER,PARTIAL_MATCHER]

Mandatory

NOOP_MATCHER

accepted_status_code

To validate/check if the api call status code is within the one of the accepted_status_code. Should be one or list of status codes

Comma separated numbers

Mandatory

201

Test_Scenarios:

This represents the logical grouping of similar scenarios.

Header Name Description Format Mandatory/Optional Example

scenario_unique_name

Name of the Test Suite Execution. should be unique. Duplicate names should not exist.

String

Mandatory

get_user_exec

test_suite

The "suite_unique_name" field value read from the Test_Suite sheets for the respective test Suite.

String

Mandatory

user_service_suite

test_cases

The "case_unique_name" field value read from test_definition sheets. Need to define that this test execution will be invoking test_definition provided in this field. Eg: get_user . The test_definition with ‘get_user’ case_unique_name will be invoked for testing.

String

Mandatory

get_user

depends_on

Sometimes other Test Suite Execution should be invoked before current Test Suite Execution. Name of the test_execution_unique_name which should execute first before executioning the current Test Suite Execution.

Comma separated String

Optional

create_user_exec

scenario_params

Parameters to be included to the current Test suite execution

Json

Optional

{"user_name" : "Kim"}

scenario_enabled

To enable or disable invocations of test suite execution . Default : TRUE.

Boolean

Optional

TRUE

assertion

Any additional assertions that has to be made on top of the tests that are executed at the API level { "Assert1": { "condition": [ "<assert_type>", "<actual>",<expected> ], "message": "<message>" } } . eg: To check if the response payload of depends_on’s test suite execution has a field value as expected.

Json

Optional

{ "Assert1": { "condition": [ "equal", "${user_exec.user_api.response[0].name}", "Tom"],"message": "Validation success" }, "Assert2": {"condition": [ "not_null", "${user_exec.user_api.response[0].id}"],"message": "Validation success" } }

function

Restel functions to modify the payloads of one test case and pass as variable/argument to another test case.Should be a predefined format:: {"<var_name>": {"operation": "<FUN_OPS>", "data": "<input>", "args": "<other args>",} } `

Json

Optional

` { "val": { "operation": "remove", "data": "${get_pet_exec.get_pet.response.groups[0]}" } }

Test_Suite:

Represents the list of suites that are part of the test.

Header Name Description Type Mandatory/Optional Example

suite_unique_name

Name of the Test Suite should be unique. Duplicate names should not exist.

String

Mandatory

user_crud_test_suite

user_service_suitesuite_description

Description about the Test suite

String

Optional

Suite to evaluate a crud on the user_service

depends_on

Sometimes other Test Suite needs to execute first before the current Test Suite. Name of the Test Suite from suite_unique_name which it depends on.

Comma Separated String

Optional

user_registration_suite,user_validation_suite

suite_params

Parameters thats need to be passed into the Test Suite APIs

Json

Optional

{"user":"John"}

suite_enable

To enable or disable invocations of APIs for the current suite. Default : TRUE.

Boolean

Optional

TRUE