Home

Автор: Джуао Фариас (João Farias)
Оригинал статьи
Перевод: Ольга Алифанова

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

Эти инструменты позволяют нам оценивать содержание ответов и время, потраченное на их получение.

Однако, помимо случаев, когда сервер дает ответ, отличный от 200 ОК, мы никогда не увидим падения.

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

• Может быть повреждено содержание ответа.
• Отдельные ответы могут занимать много времени, что неприемлемо для ряда продуктов.

К тому же нам может понадобиться изучить, как сервер реагирует в случаях, отличных от 200 ОК:

• Если ресурс не существует, достаточно ли быстро система вернет ответ 404?
• Если на сервере ошибка (код 500), продолжает ли система нормально работать?

Для ответа на эти вопросы необходимо провести дополнительную валидацию каждого запроса.

В JMeter они называются правилами (Assertions).

Давайте рассмотрим самые простые, но не менее тем полезные правила JMeter.

Типы правил

В JMeter большой выбор правил:

В этой статье мы сконцентрируемся на правиле для ответа, продолжительности, и JSON.

Правило для ответа

Правило для ответа проводит валидацию содержания ответа – как данных, так и метаданных.

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

В примере ниже мы задали валидацию ответа для всех групп потоков (заметьте, что определение находится на том же уровне, что и группы потоков).

Это правило будет реагировать (Apply to) на первый ответ (Main sample) и его перенаправления (sub-samples), если они есть.

Валидация проверяет, что код ответа – 200.

Мы можем создать какое угодно количества правил на уровне всех групп потоков.

Ниже мы проверяем, что сообщение в ответе – это ОК.

При следующем запуске все запросы снова будут зелеными, так как удовлетворяют обоим критериям.

Давайте изменим первое правило на невалидное значение – 500 (код серверной ошибки).

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

Правило продолжительности

Правила продолжительности изучают время запроса.

Так как это правило зависит от запроса, имеет смысл вводить его внутри группы потоков:

Правило продолжительности позволяет задавать приемлемое время на запрос – в нашем случае мы задали 500мс для эндпойнта Litecoin Orderbook, и 1с для эндпойнта Litecoin Trades.

В случае, если запрос не соответствует этим пределам, JMeter покажет дружелюбное сообщение об ошибке:

Правило для JSON

JSON – это расширенное правило для ответов. Его цель – упростить навигацию по JSON-ответам, просто проводя верификацию целостности данных.

В поле Assert JSON Path exists мы задаем путь JSON, и JMeter выдаст ошибку, если его не существует.

В нашем случае мы хотим проверить, что ключ asks состоит из двумерного массива. Поэтому мы ввели туда первый элемент первого элемента массива asks.

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

Для демонстрации падения я поставил галку "Противоречит правилу" ("Invert assertion") – это вызовет падение, если регулярное выражение соответствует заданному.

При помощи этих трех правил можно дальше исследовать полученные через JMeter ответы.

Скачать получившийся набор тестов можно здесь.

Как бы вы ответили на вопросы, заданные в начале этой статьи?

• Если ресурс не существует, достаточно ли быстро система вернет ответ 404?
• Если на сервере ошибка (код 500), продолжает ли система нормально работать?

Обсудить в форуме