Контент вашего веб-сайта или приложения становится недоступным из-за распределенного отказа в обслуживании (DDos) в то время, когда люди стремятся получить доступ, - это худший кошмар для любого владельца приложения. Чтобы справиться с таким сценарием, разработчики уже спроектировали и закодировали масштабируемость приложения.

Но тестируем ли мы когда-нибудь приложение для этого сценария? Мы всегда начинаем с версии приложения MVP, но в итоге доживаем до конца.

В этой статье я кратко рассмотрю некоторые основные концепции и принципы того, как k6 работает с быстрым фрагментом кода для выполнения простого теста с использованием K6.

О K6

K6 - это инструмент нагрузочного тестирования для тестирования вашего шлюза API, веб-сайтов, чтобы подготовиться к обработке большого трафика, а также тестирования вашего процесса для обработки сценариев исключений, масштабируемости и доступности ваших приложений. Он обеспечивает чистый, доступный API сценариев, локальное и облачное выполнение, а также гибкую настройку.

Давайте установим K6

Mac

Установите с помощью Homebrew, запустив:

brew install k6

Окна

Если вы используете Менеджер пакетов Chocolatey, вы можете установить неофициальный пакет k6 с помощью:

choco install k6

Докер

docker pull loadimpact/k6

Давайте протестируем…

Эта статья - всего лишь введение в K6 и быстрый шаг к тестированию производительности конечной точки.

K6 использует концепцию виртуальных пользователей (VU), которые выполняют сценарии - по сути, это восхитительные параллельные while(true) циклы. Скрипты написаны с использованием JavaScript.

Чтобы определить количество виртуальных пользователей, необходимых для оптимального тестирования вашей конечной точки, используйте приведенную ниже формулу.

Number of Virtual users (vu) = (numHourlySessions * avgSessionDurationinSecs) / 3600

Это очень легко переоценить, но выбор правильных виртуальных пользователей для теста является критическим шагом в тестах нагрузки и производительности.

Я бы рекомендовал начать тест с обычного теста для начала и моделирования для самого загруженного трафика, а затем со стресс-тестирования с максимальным количеством виртуальных пользователей (и сеансов).

Для начала воспользуйтесь приведенным ниже примером для проверки:

import http from 'k6/http';
export default function () {
  var url = 'http://api.yourplatform.com/login';
  var payload = JSON.stringify({
    email: '[email protected]',
    password: 'PASSWORD',
  });
var params = {
    headers: {
      'Content-Type': 'application/json',
    },
  };
http.post(url, payload, params);
}

Теперь возникает вопрос, мы защитили наш API-шлюз с помощью OAUTH.

Вот пример интеграции OAUTH в скрипт K6.

import http from 'k6/http';
/**
 * Authenticate using OAuth against Okta
 * @function
 * @param  {string} oktaDomain - Okta domain to authenticate against (e.g. 'k6.okta.com')
 * @param  {string} authServerId - Authentication server identifier (default is 'default')
 * @param  {string} clientId - Generated by Okta automatically
 * @param  {string} clientSecret - Generated by Okta automatically
 * @param  {string} scope - Space-separated list of scopes
 * @param  {string|object} resource - Either a resource ID (as string) or an object containing username and password
 */
export function authenticateUsingOkta(
  oktaDomain,
  authServerId,
  clientId,
  clientSecret,
  scope,
  resource,
) {
  if (authServerId === 'undefined' || authServerId == '') {
    authServerId = 'default';
  }
  let url = `https://${oktaDomain}/oauth2/${authServerId}/v1/token`;
  const requestBody = { scope: scope };
  let response;
if (typeof resource == 'string') {
    requestBody['grant_type'] = 'client_credentials';
const encodedCredentials = encoding.b64encode(
      `${clientId}:${clientSecret}`,
    );
    const params = {
      auth: 'basic',
      headers: {
        Authorization: `Basic ${encodedCredentials}`,
      },
    };
response = http.post(url, requestBody, params);
  } else if (
    typeof resource == 'object' &&
    resource.hasOwnProperty('username') &&
    resource.hasOwnProperty('password')
  ) {
    requestBody['grant_type'] = 'password';
    requestBody['username'] = resource.username;
    requestBody['password'] = resource.password;
    requestBody['client_id'] = clientId;
    requestBody['client_secret'] = clientSecret;
response = http.post(url, requestBody);
  } else {
    throw 'resource should be either a string or an object containing username and password';
  }
return response.json();
}

Подробную статью об интеграции OAUTH с конечной точкой API - https://k6.io/blog/how-to-load-test-oauth-secured-apis-with-k6

Запуск скрипта K6

Момент истины. K6 установлен и готов к выполнению скрипта.

k6 run script.js

Если это машина с Windows, вы можете заменить k6 на k6.exe.

Теперь, когда вы знаете количество виртуальных пользователей, которым вы хотите выполнить сценарий, команда для выполнения сценария будет выглядеть примерно так, как показано ниже.

k6 run -u 10 script.js

Чтобы поднять выполнение скрипта еще на один уровень, вы можете задействовать переменные среды K6.

if (__ENV.script_scenario == "staging") {
    export let options = { vus:20, };
} else {
    export let options = { vus:1, };
}

В K6 переменные среды представлены через глобальную переменную _ENV. Значение переменной может поступать из локальной системы (через команду экспорта) или быть явно передано в K6 с помощью команды -e ИМЯ = значение.

Давайте перейдем на еще один уровень, чтобы провести стресс-тестирование кода.

Настраивая аргументы командной строки, вы можете настроить количество одновременных запросов, которые вы хотите сделать. Эта команда создаст 1000 одновременных сеансов (виртуальных пользователей) и будет запускать эти отдельные запросы 10 раз для каждого виртуального пользователя, следовательно, 10 000 итераций.

k6 run -u 1000 — iterations 10000 script.js

Заключение

Я полагаю, что эта статья должна была дать вам быстрый взгляд на K6 и сценарий для тестирования вашей конечной точки.

На рынке существует множество инструментов для выполнения нагрузочных и стресс-тестов приложения. Эта статья - просто мое путешествие по использованию простого в использовании инструмента с открытым исходным кодом для тестирования конечной точки API.

Это всего лишь введение в K6, и в нашем сценарии мы использовали Postman для тестирования конечной точки API. Интеграция теста Postman с использованием newman как части конвейера сборки и развертывания помогла нам выполнить интегрированный сквозной тест.

Следующая статья будет посвящена прохождению теста Postman и его использованию для выполнения нагрузочного / стресс-теста на конечной точке.

Буду рад узнать о вашем путешествии по нагрузочному тестированию и ваши отзывы / вопросы по этой статье.

Спасибо за чтение.

использованная литература





Больше контента на plainenglish.io