pandora

Home

Scenario generator / HTTP

Configuration

You need to use a generator and a provider of type http/scenario

pools:
  - id: Pool name
    gun:
      type: http/scenario
      target: localhost:80
    ammo:
      type: http/scenario
      file: payload.hcl

Generator

The minimum generator configuration is as follows

gun:
  type: http/scenario
  target: localhost:80

There is also a type: http2/scenario generator

gun:
  type: http2/scenario
  target: localhost:80

All the settings of the regular HTTP generator are supported for the scenario generator

Provider

The provider accepts only one parameter - the path to the file with the scenario description

ammo:
  type: http/scenario
  file: payload.hcl

Supports file extensions

Description of the scenario format

Supports formats

General principle

Several scenarios can be described in one file. A scenario has a name that distinguishes one scenario from another.

A scenario is a sequence of requests. That is, you will need to describe in the script which requests in what order should be executed.

Request - HTTP request. Has the standard HTTP request fields plus additional fields. See Requests.

HCL example

variable_source "source_name" "file/csv" {
  file              = "file.csv"
  fields            = ["id", "name"]
  ignore_first_line = true
  delimiter         = ","
}

request "request_name" {
  method  = "POST"
  uri     = "/uri"
  headers = {
    HeaderName = "header value"
  }
  tag       = "tag"
  body      = <<EOF
<body/>
EOF

  templater {
    type = "text"
  }

  preprocessor {
    mapping = {
      new_var = "source.var_name[next].0"
    }
  }
  postprocessor "var/jsonpath" {
    mapping = {
      new_var = "$.auth_key"
    }
  }
}


scenario "scenario_name" {
  weight           = 1
  min_waiting_time = 1000
  requests         = [
    "request_name",
  ]
}

YAML example

variable_sources:
  - type: "file/csv"
    name: "source_name"
    ignore_first_line: true
    delimiter: ","
    file: "file.csv"
    fields: [ "id", "name" ]

requests:
  - name: "request_name"
    uri: '/uri'
    method: POST
    headers:
      Header-Name: "header value"
    tag: tag
    body: '<body/>'
    preprocessor:
      mapping:
        new_var: source.var_name[next].0
    templater:
      type: text
    postprocessors:
      - type: var/jsonpath
        mapping:
          token: "$.auth_key"

scenarios:
  - name: scenario_name
    weight: 1
    min_waiting_time: 1000
    requests: [
      request_name
    ]

Features

Requests

Поля

Templater

The uri, headers, body fields are templatized.

The standard go template is used.

Variable names in templates

Variable names have the full path of their definition.

For example

Variable users from source user_file - {{.source.user_file.users}}

Variable token from the list_req query postprocessor - {{.request.list_req.postprocessor.token}}

Variable item from the list_req query preprocessor - {{.request.list_req.preprocessor.item}}

Functions in Templates

Since the standard Go templating engine is used, it is possible to use built-in functions available at https://pkg.go.dev/text/template#hdr-Functions.

Additionally, some functions include:

For more details about randomization functions, see more.

Preprocessors

Preprocessor - actions are performed before templating

It is used for creating new variable mapping

The preprocessor has the ability to work with arrays using modifiers

yaml
requests:
  - name: req_name
    ...
    preprocessor:
      mapping:
        user_id: source.users[next].id
hcl
request "req_name" {
  preprocessor {
    mapping = {
      user_id = "source.users[next].id"
    }
  }
}

Additionally, in the preprocessor, it is possible to create variables using randomization functions:

For more details about randomization functions, see more.

Postprocessors

var/jsonpath

HCL example

postprocessor "var/jsonpath" {
  mapping = {
    token = "$.auth_key"
  }
}
var/xpath
postprocessor "var/xpath" {
  mapping = {
    data = "//div[@class='data']"
  }
}
var/header

Creates a new variable from response headers

It is possible to specify simple string manipulations via pipe

postprocessor "var/header" {
  mapping = {
    ContentType      = "Content-Type|upper"
    httpAuthorization = "Http-Authorization"
  }
}
assert/response

Checks header and body content

Upon assertion, further scenario execution is dropped

postprocessor "assert/response" {
  headers = {
    "Content-Type" = "application/json"
  }
  body        = ["token"]
  status_code = 200

  size {
    val = 10000
    op  = ">"
  }
}

Scenarios

The minimum fields for the script are name and list of requests

scenario "scenario_name" {
  requests = [
    "list_req",
    "order_req",
    "order_req",
    "order_req"
  ]
}

You can specify a multiplicator for request repetition

scenario "scenario_name" {
  requests = [
    "list_req",
    "order_req(3)"
  ]
}

You can specify the sleep() delay. Parameter in milliseconds

scenario "scenario_name" {
  requests = [
    "list_req",
    "sleep(100)",
    "order_req(3)"
  ]
}

The second argument to request is sleep for requests with multipliers

scenario "scenario_name" {
  requests = [
    "list_req",
    "sleep(100)",
    "order_req(3, 100)"
  ]
}

The min_waiting_time parameter describes the minimum scenario execution time. That is, a sleep will be added at the end of the entire scenario if the scenario is executed faster than this parameter.

scenario "scenario_name" {
  min_waiting_time = 1000
  requests         = [
    "list_req",
    "sleep(100)",
    "order_req(3, 100)"
  ]
}

Multiple scenarios can be described in one file.

The weight parameter is the distribution weight of each scenario. The greater the weight, the more often the scenario will be executed.

scenario "scenario_first" {
  weight   = 1
  requests = [
    "auth_req(1, 100)",
    "list_req(1, 100)",
    "order_req(3, 100)"
  ]
}

scenario "scenario_second" {
  weight   = 50
  requests = [
    "mainpage",
  ]
}

Sources

Follow - Variable sources

References

Home

This site is open source. Improve this page.