Кто проводит нагрузочное тестирование?

Question

Кто проводит нагрузочное тестирование?

Тип вопроса: Тестирование производительности Вероятность: 10% Категория: QA Тестировщик

Ответ

Проведение нагрузочного тестирования — это зона ответственности нескольких ролей:

Performance Test Engineer / QA Performance — ключевой специалист. Отвечает за планирование, выполнение тестов, анализ результатов и поиск узких мест.
DevOps-инженер — помогает с развертыванием и настройкой тестового окружения, интеграцией тестов в CI/CD, сбором метрик инфраструктуры (CPU, память, сеть).
Разработчик — участвует в анализе результатов, особенно для поиска и устранения узких мест в коде (например, неоптимальных запросов к БД).

Пример сценария нагрузочного теста на k6:

import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate } from 'k6/metrics';

const errorRate = new Rate('errors');

export const options = {
  stages: [
    { duration: '2m', target: 100 },  // Наращивание нагрузки до 100 VU
    { duration: '5m', target: 100 },  // Стабильная нагрузка
    { duration: '1m', target: 0 },    // Снижение нагрузки
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% запросов должны быть быстрее 500мс
    'errors': ['rate<0.01']           // Частота ошибок менее 1%
  }
};

export default function () {
  const res = http.get('https://api.example.com/items');
  const success = check(res, {
    'status is 200': (r) => r.status === 200,
  });
  errorRate.add(!success);
  sleep(1);
}

Необходимые навыки для performance-инженера: знание инструментов (JMeter, Gatling, k6), понимание метрик (RPS, latency, throughput, перцентили), умение анализировать логи и данные мониторинга (Grafana, APM-инструменты), базовые знания сетей и инфраструктуры.

Ответ 18+ 🔞

Да ты посмотри, какая тут, блядь, компания подбирается! Нагрузочное тестирование — это ж не один мудак с кнопкой «старт» сидит, это целый цирк с конями, ебать мои старые костыли.

Кто тут у нас главный по тарелочкам?

Performance Test Engineer / QA Performance — это, сука, капитан корабля, который в ад и обратно. Он всё планирует, тесты эти ёбаные гоняет, результаты смотрит и ищет, где система пыхтит и трещит. Без него — нихуя.
DevOps-инженер — это наш волшебник-настройщик. Он тестовое окружение из пальца выдувает, в CI/CD эту всю хуйню засовывает, чтобы само бегало, и метрики инфраструктуры (процессор, память, сеть) собирает. Без него капитан на мели, блядь.
Разработчик — а этот товарищ подключается, когда уже нашли слабое звено. Ему тыкают в нос графиком и говорят: «Смотри, сука, твой запрос к базе данных тормозит, как черепаха в сиропе! Иди-ка, чини свою лажу». Без его участия все выводы — просто пиздёж в пустоту.

Вот, смотри, как на k6 простой сценарий выглядит, чтоб ты понимал масштаб:

import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate } from 'k6/metrics';

const errorRate = new Rate('errors');

export const options = {
  stages: [
    { duration: '2m', target: 100 },  // Плавно нагоняем до 100 виртуальных юзеров
    { duration: '5m', target: 100 },  // Держим нагрузку, смотрим, не сдохнет ли
    { duration: '1m', target: 0 },    // Плавно отпускаем, даём отдышаться
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% запросов должны уложиться в 500 мс, иначе пиздец
    'errors': ['rate<0.01']           // Ошибок должно быть меньше 1%, иначе тоже пиздец
  }
};

export default function () {
  const res = http.get('https://api.example.com/items');
  const success = check(res, {
    'status is 200': (r) => r.status === 200,
  });
  errorRate.add(!success);
  sleep(1);
}

А что должен знать этот самый performance-инженер, чтобы не быть, прости господи, мартышкой с гранатой? Знать инструменты (JMeter, Gatling, k6 — хоть один, но в лицо), понимать, что значат метрики (RPS, latency, throughput, перцентили — это не просто умные слова, а сигналы беды). Уметь ковыряться в логах и разбираться в мониторинге (Grafana и прочие APM-инструменты — его лучшие друзья). И, конечно, базово шарить по сетям и инфраструктуре, чтобы, когда всё легло, не говорить «ой, а интернет-то кончился». Вот тогда, может, и выйдет что-то путное, а не просто пыль в глаза.