Контент вашего веб-сайта или приложения становится недоступным из-за распределенного отказа в обслуживании (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