Loadero usage

Loadero offers multiple features that could be used to improve work in multiple ways. This section will describe available features implemented.

For more information, feel free to contact support.

Client AWS account

Loadero offers an option for clients to use their own AWS accounts to run test nodes. This allows more control over node billing and management, although it is advised not to tamper test nodes during execution.

Requirements from client

• AWS account id (12 digit number)
• API access key id
• API access key secret

AWS account should have two policies attached:

• AmazonEC2FullAccess
• AmazonS3FullAccess

The account should have Hong Kong region enabled, otherwise Loadero will not be able to use that account.

Each of these requirements is necessary for node setup in client's environment. Since we need to prepare media files and dependencies, that take up a lot of space, it is unreasonable to create launcher scripts that would prepare all this environment for each new test run.

Security concerns

Handing out API access key and secret may seem like direct security hole. But all of this is necessary for us to launch tests on client's AWS. For additional security, new IAM user should be created for the sole purpose of running Loadero tests. This user will not have access to any nodes launched from other users and environments, thus limiting any possible out of scope actions for Loadero. Also, having separate IAM role will allow main user to control billing and running nodes that are launched by Loadero account.

Direct API access

Loadero has an exposed REST API that can be used to control test creation and execution without the need of frontend application.

[!NOTE]

REST API is accessible only to paid projects.

Documentation

There is documentation of API available in form of swagger 2.0 doc. It is available here.

Auth API Access

All Loadero API endpoints are secured by oAuth 2.0 authorization protocol. To get your auth token it's required to authorize your account using client credentials in our oAuth server, after that oAuth will provide you with an access token that can be used to authenticate Loadero API requests.

Get access token

To authorize your account using username and password, it's required to send a POST request to our oAuth server's /auth/token endpoint. This request has to be also authenticated with your client_id and client_secret encoded to base64, this will serve as a Basic token. There are four request parameters that have to be set for a successful authorization. It's required that grant_type is set to password. Also username and password parameters are required to authorize account, keep in mind that these are your Loadero account credentials. Last one is scope which should include all the required scopes for your tasks joined with a + sign. Check out an cURL request example below! All of Loadero scopes can be found in our APIs swagger documentation. It is available here.

cURL example

[!EXAMPLE]

curl -X POST https://auth.loadero.com/auth/token/ \
    -H "Authorization: Basic base64(`client_id`:`client_secret`)" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -d "grant_type=password" \
    -d "username=exampleUsername" \
    -d "password=examplePassword" \
    -d "scope=TEST_CREATE+TEST_UPDATE+PROJECT_READ"

Auth response example

[!EXAMPLE]

{
    "access_token": "EXAMPLEACCESSTOKEN",
    "refresh_token": "EXAMPLEREFRESHTOKEN",
    "expires_in": 3600,
    "scopes": ["TEST_CREATE", "TEST_UPDATE", "PROJECT_READ"],
    "token_type": "Bearer"
}

Access token usage example

[!EXAMPLE]

curl -X GET https://api.loadero.com/v2/projects/{project_id} \
    -H "Authorization: Bearer EXAMPLEACCESSTOKEN"

Member Permissions

Within a project all members have an assigned role that dictates the action this member is allowed to perform. Currently there are three member roles in Loadero. Each role gives a bundle of permitted actions.

[!NOTE]

Project creator automatically gains Administrator role.

Specific Member Role Permissions

This table below summarizes what actions can be performed by each role, to help picking the appropriate role a member.

Participant Count Calculations

Loadero has monthly used participant count limitations for certain payment plans which limits the amount tests you are able to run each month. Each participant browser instance launched in a test counts as one used participant.

We are calculating used participants in all project test runs which are:

• Pending execution
• Running
• Have been aborted while running
• Have timed out
• Has finished test execution

Test runs which encountered server error will not be counted.

The limit will be reset at midnight of the first day of the month by UTC time.

In-test Downloads

Loadero offers to download files in your performance test (NOT available in load test and session recording) if their combined size does not exceed 100 MB and retrieve them later in the test results tab. Files are not accessible in the test, but rather as artifacts after the test has finished. All artifacts will be individually compressed to gzip (.gz) archive.

[!WARNING] It is impossible to download files directly via URL on Firefox. You can download them via indirect path, e.g., via "Download" button in front-end interface.

[!NOTE]

In case 100 MB limit is exceeded, results won't be uploaded to our servers at all, therefore you will not see them under artifacts.

[!NOTE]

If in the test you are downloading files, e.g., PDF file or video, you have to consider that in your test script since the test will not wait until the download is completed.