Как часто нужно выполнять нагрузочное тестирование

Как Часто Выполнять Нагрузочное Тестирование

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

Критерии для Определения Частоты

1. Критичность приложения:

• E-commerce, Banking, Healthcare: Минимум 1-2 раза в месяц + перед релизом
• SaaS, корпоративные системы: 1 раз в квартал + перед major релизом
• Internal tools: По необходимости при существенных изменениях

2. Объем изменений кода:

• Новый код в critical paths → нагрузочное тестирование
• Оптимизация БД → обязательно
• Новые dependencies/libraries → проверить
• Простые UI изменения → не обязательно

3. Известные проблемы:

• Если история конкретных issues с нагрузкой → регулярные тесты
• Если есть bottleneck → тест после каждого fix

Рекомендуемая Стратегия

Baseline (Базовый) Тест:

Частота: При старте проекта, затем при существенных изменениях
Цель: Определить норму (baseline) производительности
Нагрузка: Среднее ожидаемое использование
Длительность: 10-30 минут

Примеры:
- 100 RPS (requests per second) в течение 15 минут
- Проверка утечек памяти

Regression Tests (Регрессионные):

Частота: Перед каждым Production релизом
Цель: Убедиться, что нет деградации
Нагрузка: Средняя + Пиковая
Длительность: 10-20 минут

Примеры:
- Тот же сценарий, что и baseline
- Сравнение результатов

Stress Tests (Стресс-тесты):

Частота: 1-2 раза в квартал + перед большими событиями
Цель: Найти точку отказа (breaking point)
Нагрузка: До 3-5x от пиковой ожидаемой
Длительность: 30-60 минут

Примеры:
- 500-1000 RPS для критичного сервиса
- Проверка поведения при OutOfMemory

Spike Tests (Всплески):

Частота: 2-4 раза в год
Цель: Проверить реакцию на неожиданный всплеск
Нагрузка: Резкое увеличение (от 100 до 500 RPS за секунды)
Длительность: 5-10 минут

Сценарий: Black Friday, акция, вирусный контент

Endurance Tests (Выносливость):

Частота: 1 раз в квартал для critical систем
Цель: Обнаружить утечки памяти, деградацию
Нагрузка: Средняя, но длительная
Длительность: 2-8 часов

Примеры:
- 50 RPS в течение 4 часов
- Проверка GC pauses

Практический График по Типам Приложений

Финтех / E-commerce / Banking:

Перед каждым релизом: Regression test (30 мин)
Каждую неделю: Baseline (15 мин)
Каждый месяц: Stress test (1 час)
Квартально: Endurance test (4 часа)

После известных проблем: Тест в течение 48 часов

SaaS / Веб-приложение:

Перед каждым релизом: Regression test (20 мин)
Каждый месяц: Baseline (15 мин)
Квартально: Stress test (1 час)
Полугодие: Endurance test (2 часа)

Internal Tools / Back-office:

Перед releaseом: Быстрая регрессия (10 мин)
При известных проблемах: Тест затронутого функционала
Нет необходимости в регулярных тестах

Пример: JMeter Script для Автоматизации

// TestRunner.java - автоматизированное нагрузочное тестирование
public class LoadTestRunner {
    
    public static void main(String[] args) throws Exception {
        // Создаём JMeter тест план
        HashTree testPlan = createTestPlan();
        
        // Запускаем тест
        StandardJMeterEngine jmeter = new StandardJMeterEngine();
        jmeter.configure(testPlan);
        
        // Слушаем результаты
        Summariser summer = new Summariser("summary");
        ResultCollector collector = new ResultCollector(summer);
        testPlan.getFirst().addListener(collector);
        
        // Запуск
        jmeter.run();
    }
    
    private static HashTree createTestPlan() {
        // Используем конфигурацию
        HTTPSamplerProxy sampler = new HTTPSamplerProxy();
        sampler.setDomain("api.example.com");
        sampler.setPort(443);
        sampler.setProtocol("https");
        sampler.setPath("/api/v1/users");
        sampler.setMethod("GET");
        
        // Настройка нагрузки: 100 пользователей, 10 сек ramp-up
        ThreadGroupGui threadGroup = new ThreadGroupGui();
        threadGroup.setNumThreads(100);
        threadGroup.setRampTime("10");
        threadGroup.setLoops(1);
        
        // Собираем план
        HashTree hashTree = new HashTree();
        hashTree.add(threadGroup);
        hashTree.get(threadGroup).add(sampler);
        
        return hashTree;
    }
}

Облачные Инструменты для Нагрузочного Тестирования

1. Apache JMeter:

# Запуск baseline теста
jmeter -n -t baseline_test.jmx -l results.jtl

# GUI для создания тестов
jmeter -g results.jtl -j jmeter.log

2. Gatling (Scala DSL):

import io.gatling.core.Predef._
import io.gatling.http.Predef._

class LoadSimulation extends Simulation {

  val httpProtocol = http
    .baseUrl("http://example.com")
    .acceptHeader("application/json")

  val scn = scenario("BaselineLoad")
    .exec(http("Get Users")
      .get("/api/users")
      .check(status.is(200)))

  // Baseline: 100 RPS в течение 10 минут
  setUp(
    scn.inject(
      constantUsersPerSec(100).during(10 minutes)
    ).protocols(httpProtocol)
  )
}

3. k6 (JavaScript):

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

export const options = {
  vus: 100,           // 100 virtual users
  duration: '15m',     // 15 minutes
  thresholds: {
    http_req_duration: ['p(99)<500'],  // 99% ответов < 500ms
    http_req_failed: ['rate<0.1'],     // Меньше 0.1% ошибок
  },
};

export default function () {
  const response = http.get('https://api.example.com/users');
  
  check(response, {
    'status is 200': (r) => r.status === 200,
    'response time < 1s': (r) => r.timings.duration < 1000,
  });
  
  sleep(1);
}

Интеграция в CI/CD Pipeline

GitHub Actions пример:

name: Load Testing

on:
  pull_request:
    paths:
      - 'src/**'
  schedule:
    - cron: '0 2 * * MON'  # Еженедельно по понедельникам

jobs:
  load_test:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v2
      
      - name: Run Load Test
        run: |
          docker run --rm -v $PWD:/workspace \
            grafana/k6 run /workspace/load_test.js
      
      - name: Check Results
        run: |
          # Сравнить с baseline
          if [ $LOAD_TEST_FAILED == true ]; then
            echo "Load test failed!"
            exit 1
          fi

Критерии Успешного Теста

public class LoadTestCriteria {
    
    // Response time
    public static final long P99_RESPONSE_TIME = 500;  // ms
    public static final long P95_RESPONSE_TIME = 300;  // ms
    public static final long AVERAGE_RESPONSE_TIME = 150;  // ms
    
    // Errors
    public static final double ERROR_RATE_THRESHOLD = 0.01;  // 1%
    public static final int ACCEPTABLE_ERRORS = 5;  // на 1000 requests
    
    // Throughput
    public static final int MIN_REQUESTS_PER_SEC = 100;
    
    // Memory
    public static final long MAX_HEAP_USAGE = 2000;  // MB
    public static final long ACCEPTABLE_GC_PAUSE = 200;  // ms
    
    public static boolean validateResults(LoadTestResults results) {
        return results.getP99ResponseTime() <= P99_RESPONSE_TIME
            && results.getErrorRate() <= ERROR_RATE_THRESHOLD
            && results.getRequestsPerSecond() >= MIN_REQUESTS_PER_SEC
            && results.getMaxHeapUsage() <= MAX_HEAP_USAGE;
    }
}

Анализ Результатов

Что смотреть в отчёте:

• Response Time Percentiles:

  • p50 (median) — типичный пользователь
  • p95 — медленные пользователи
  • p99 — очень медленные
  • max — худший случай

• Error Rate: Должно быть < 0.1%

• Throughput: Стабилен ли под нагрузкой?

• Memory Usage: Растёт ли? (признак утечки)

• GC Pauses: Не должны быть > 200ms

Рекомендуемая Частота (Summary)

Минимум:

• Перед каждым production релизом: Regression test
• При изменениях в critical code: Baseline test

Оптимально:

• Еженедельно: Automated baseline test
• Ежемесячно: Stress test
• Ежеквартально: Endurance test
• По требованию: Spike test

Максимум:

• Критичные системы: Ежедневно (автоматизированно)

Заключение

Частота нагрузочного тестирования должна соответствовать:

• Критичности приложения
• Историческим проблемам с производительностью
• Объёму и типу изменений кода
• Бюджету (тесты требуют времени и ресурсов)

Идеальный подход: Автоматизированное тестирование в CI/CD + регулярные ручные тесты.