Lesson 15 of 26

Урок 15 — Performance Testing

Название: Performance Testing — комплексная оценка производительности системы
Описание: Разбираем тестирование производительности: что входит в это понятие, какие метрики важны, какие инструменты использовать и как оценивать производительность веб-приложений.
Почему это важно для QA: Медленное приложение — это баг. Пользователи уходят, если страница грузится дольше 3 секунд. Понимание Performance Testing — обязательный навык для QA среднего уровня.

1. Что такое Performance Testing

Performance Testing (тестирование производительности) — это широкая категория нефункционального тестирования, которая оценивает скорость, стабильность и масштабируемость системы под разными условиями нагрузки.

Performance Testing — это зонтичный термин, под которым объединяются:

Performance Testing
├── Load Testing (нагрузочное тестирование)
├── Stress Testing (стресс-тестирование)
├── Spike Testing (тест на скачки нагрузки)
├── Soak / Endurance Testing (длительная нагрузка)
├── Scalability Testing (масштабируемость)
└── Volume Testing (тест с большим объёмом данных)

2. Ключевые метрики производительности

2.1 Время отклика (Response Time)

Время от отправки запроса до получения ответа.

Отличное:  < 100 мс (мгновенно для пользователя)
Хорошее:   100–300 мс
Приемлемое: 300–1000 мс
Плохое:    > 1000 мс (пользователь замечает задержку)
Критичное: > 3000 мс (высокий риск ухода пользователя)

2.2 Пропускная способность (Throughput)

Количество запросов, которые система обрабатывает в единицу времени.

RPS (Requests Per Second) — запросов в секунду
TPS (Transactions Per Second) — транзакций в секунду

2.3 Использование ресурсов

Ресурс	Нормальный диапазон	Критический
CPU	< 70%	> 90%
RAM	< 75%	> 90%
Disk I/O	Зависит от железа	Очередь > 100 мс
Network	< 70% от пропускной	> 90%

2.4 Перцентили времени отклика

P50 (медиана): 50% пользователей получают ответ быстрее этого времени
P90:           90% пользователей получают ответ быстрее этого времени
P95:           95% пользователей получают ответ быстрее этого времени
P99:           99% пользователей получают ответ быстрее этого времени

Золотой стандарт: P99 < 1 сек для API

2.5 Error Rate

Отличное:    0% (нет ошибок)
Приемлемое:  < 0.1%
Допустимое:  < 1%
Критичное:   > 1%

3. Web Vitals — производительность глазами Google

Google использует набор метрик Core Web Vitals для оценки пользовательского опыта:

Метрика	Расшифровка	Хороший показатель	Что измеряет
LCP	Largest Contentful Paint	< 2.5 сек	Время загрузки основного контента
INP	Interaction to Next Paint	< 200 мс	Отзывчивость на действия
CLS	Cumulative Layout Shift	< 0.1	Стабильность макета
FCP	First Contentful Paint	< 1.8 сек	Первый элемент на экране
TTFB	Time to First Byte	< 800 мс	Время до первого байта ответа

Аналогия

LCP — когда ты открываешь книгу и видишь первую важную иллюстрацию
INP — нажимаешь кнопку и сразу видишь реакцию
CLS — читаешь текст, и он не «прыгает» пока страница загружается

4. Инструменты Performance Testing

4.1 Для Load / Stress тестирования

Инструмент	Язык	Особенность
k6	JavaScript	Современный, для CI/CD
JMeter	GUI	Классика, мощный
Gatling	Scala	Хорошие HTML-отчёты
Locust	Python	Простой старт
Artillery	JS/YAML	Cloud-native

4.2 Для Frontend Performance

Инструмент	Где использовать	Что измеряет
Lighthouse	Chrome DevTools, CLI, CI	Web Vitals, Best Practices
WebPageTest	webpagetest.org	Детальный анализ загрузки
Chrome DevTools Performance	Браузер	Профилирование JS, рендеринга
PageSpeed Insights	pagespeed.web.dev	Google Web Vitals оценка

5. Тестирование Frontend производительности

Lighthouse в Playwright

typescripttypescript

import { test } from "@playwright/test";
import { playAudit } from "playwright-lighthouse";
import lighthouse from "lighthouse";

const PERFORMANCE_THRESHOLDS = {
  performance: 80,
  accessibility: 90,
  "best-practices": 85,
  seo: 80,
} as const;

test("главная страница проходит Lighthouse аудит", async ({ page, browser }) => {
  const port = new URL(browser.wsEndpoint()).port;

  await page.goto("https://staging.shop.example.com/");

  await playAudit({
    page,
    port: Number(port),
    thresholds: PERFORMANCE_THRESHOLDS,
    reports: {
      formats: { html: true },
      name: "homepage-lighthouse",
      directory: "./lighthouse-reports",
    },
  });
});

Измерение Web Vitals через Playwright

typescripttypescript

import { test, expect } from "@playwright/test";

interface WebVitals {
  lcp: number;
  fcp: number;
  cls: number;
}

const WEB_VITALS_THRESHOLDS = {
  lcp: 2500,    // мс
  fcp: 1800,    // мс
  cls: 0.1,     // единицы
} as const;

test("Web Vitals главной страницы в норме", async ({ page }) => {
  const vitals: Partial<WebVitals> = {};

  await page.addInitScript(() => {
    new PerformanceObserver((list) => {
      for (const entry of list.getEntries()) {
        if (entry.entryType === "largest-contentful-paint") {
          (window as unknown as Record<string, unknown>).__lcp = entry.startTime;
        }
      }
    }).observe({ entryTypes: ["largest-contentful-paint"] });
  });

  await page.goto("/");
  await page.waitForLoadState("networkidle");

  const lcp = await page.evaluate(() => (window as unknown as Record<string, unknown>).__lcp as number);
  const fcp = await page.evaluate(() => {
    const entries = performance.getEntriesByName("first-contentful-paint");
    return entries[0]?.startTime ?? 0;
  });

  vitals.lcp = lcp;
  vitals.fcp = fcp;

  expect(vitals.lcp, `LCP должен быть < ${WEB_VITALS_THRESHOLDS.lcp}мс`).toBeLessThan(
    WEB_VITALS_THRESHOLDS.lcp
  );
  expect(vitals.fcp, `FCP должен быть < ${WEB_VITALS_THRESHOLDS.fcp}мс`).toBeLessThan(
    WEB_VITALS_THRESHOLDS.fcp
  );
});

6. Анализ производительности в Chrome DevTools

Вкладка Network

Что смотрим:

Waterfall — порядок загрузки ресурсов
Blocking time — время ожидания сервера (TTFB)
Size — размер файлов (большие → медленная загрузка)
Time — время загрузки каждого ресурса

Типичные проблемы, которые видно в Network

❌ JavaScript bundle 5 МБ → нужен code splitting
❌ Изображения не сжаты (PNG 2 МБ) → нужен WebP + lazy loading
❌ Много последовательных запросов → нужна параллелизация
❌ Высокий TTFB (> 2 сек) → проблема на сервере или БД
❌ Нет кеширования (Cache-Control: no-cache) → каждый раз загружается заново

7. Performance Test Plan — как планировать

ПЛАН ТЕСТИРОВАНИЯ ПРОИЗВОДИТЕЛЬНОСТИ
══════════════════════════════════════
Цель: Убедиться, что v3.0.0 готова к пиковому трафику

МЕТРИКИ И ЦЕЛЕВЫЕ ЗНАЧЕНИЯ:
├── P95 время отклика API: < 300 мс
├── P99 время отклика API: < 1 сек
├── Throughput: > 1000 RPS
├── Error rate: < 0.5%
├── CPU при нагрузке: < 70%
└── LCP главной страницы: < 2.5 сек

ТЕСТЫ:
1. Baseline Test (10 VU, 5 мин) — эталон без нагрузки
2. Load Test (500 VU, 20 мин) — ожидаемая нагрузка
3. Stress Test (нарастание до 5000 VU) — предел системы
4. Spike Test (0 → 3000 VU за 30 сек) — вирусный трафик
5. Soak Test (300 VU, 8 часов) — утечки памяти

ОКРУЖЕНИЕ:
├── Staging: 2 сервера, 8 CPU, 16 GB RAM
└── БД: PostgreSQL 15, отдельный сервер

8. Частые ошибки

❌ Тестируют производительность только перед крупным релизом
→ Performance — это непрерывный процесс. Встраивай в CI.

❌ Сравнивают только среднее время отклика
→ Используй P90, P95, P99. Среднее маскирует проблемы.

❌ Не тестируют фронтенд производительность
→ Lighthouse + Web Vitals обязательны для любого веб-приложения.

❌ Не устанавливают baseline (эталон)
→ Без базовых показателей непонятно: стало хуже или лучше?

Итог

PERFORMANCE TESTING — это зонтичный термин:
├── Load Testing — под ожидаемой нагрузкой
├── Stress Testing — за пределами нормы
├── Spike Testing — резкие скачки
├── Soak Testing — длительная нагрузка
└── Web Performance — Lighthouse, Web Vitals

Ключевые метрики: Response Time (P95/P99), Throughput, Error Rate
Ключевые инструменты: k6, JMeter, Lighthouse, Chrome DevTools
Главное правило: устанавливай baseline и сравнивай с ним