Нагрузка, безопасность и метрики качества

Финальный блок собеседования на middle и senior: нефункциональные виды тестирования и умение говорить с менеджментом на языке цифр.

Функциональное тестирование отвечает на вопрос «работает ли». Нефункциональное — «как именно работает»: быстро ли, под нагрузкой ли, безопасно ли, удобно ли.

Вопрос 1: «Какие виды нагрузочного тестирования знаете?»

Что на самом деле проверяет интервьюер

Различаете ли вы цели проверок. Слово «нагрузочное» часто используют как зонтик для четырёх разных вещей.

Развёрнутый ответ

Вид	Профиль нагрузки	Вопрос, на который отвечает
Load	ожидаемая рабочая	держим ли мы обычный трафик в рамках SLA?
Stress	растущая до отказа	где предел и как система деградирует?
Spike	резкий всплеск	переживём ли распродажу или рассылку?
Soak (endurance)	умеренная, но долгая	нет ли утечек памяти и роста времени ответа за сутки?
Scalability	рост нагрузки и ресурсов	помогает ли добавление серверов?

Показатели, которые нужно называть: пропускная способность (RPS), время ответа в перцентилях, доля ошибок, утилизация CPU и памяти. Важная деталь для сильного ответа: смотреть надо не среднее время ответа, а перцентили. Среднее в 200 мс прекрасно уживается с ситуацией, когда каждый двадцатый пользователь ждёт восемь секунд, — это видно только по p95 и p99. Инструменты стоит назвать: JMeter, k6, Gatling, Locust.

Вопрос 2: «Что тестировщик может проверить по безопасности без специальных знаний?»

Развёрнутый ответ

Полноценный пентест — отдельная профессия, но базовый чек-лист входит в обязанности функционального тестировщика:

Права доступа и IDOR: подставить чужой id в URL или в тело запроса, вызвать «админский» эндпоинт токеном обычного пользователя.
Аутентификация: работает ли выход из аккаунта, инвалидируется ли токен, есть ли ограничение попыток входа, не остаётся ли сессия активной после смены пароля.
Валидация ввода: базовые проверки на XSS (<script> в поле имени, потом просмотр этого имени в другом месте) и на SQL-инъекции (кавычка в параметре — 500 в ответ является тревожным сигналом).
Утечки данных: лишние поля в ответах API, чувствительные данные в логах и URL, подробные стек-трейсы на проде.
Транспорт: HTTPS везде, флаги cookie Secure и HttpOnly, отсутствие токенов в query-параметрах.

Обязательная оговорка на собеседовании: проверки безопасности выполняются только на тестовых стендах и по согласованию — самодеятельность на продакшене недопустима.

Вопрос 3: «Какими метриками измеряют качество?»

Что на самом деле проверяет интервьюер

Понимаете ли вы, что метрику легко превратить в оружие против команды.

Развёрнутый ответ

Полезные метрики: DDP (defect detection percentage) — доля дефектов, найденных до релиза; количество дефектов, «просочившихся» в продакшен; плотность дефектов по модулям; время от заведения до исправления; доля упавших релизов; стабильность автотестов.

CREATE TABLE defects (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  module TEXT,
  severity TEXT,
  found_in TEXT
);

INSERT INTO defects (module, severity, found_in) VALUES
  ('checkout', 'blocker',  'testing'),
  ('checkout', 'major',    'testing'),
  ('checkout', 'minor',    'production'),
  ('search',   'major',    'testing'),
  ('search',   'trivial',  'testing'),
  ('profile',  'critical', 'production'),
  ('profile',  'major',    'testing'),
  ('profile',  'minor',    'testing'),
  ('cart',     'blocker',  'testing'),
  ('cart',     'major',    'production');

SELECT
  module,
  COUNT(*) AS total,
  SUM(CASE WHEN found_in = 'production' THEN 1 ELSE 0 END) AS escaped,
  ROUND(100.0 * SUM(CASE WHEN found_in = 'testing' THEN 1 ELSE 0 END) / COUNT(*), 1) AS ddp
FROM defects
GROUP BY module
ORDER BY escaped DESC, module;

Вывод:

module    total  escaped  ddp
cart      2      1        50.0
checkout  3      1        66.7
profile   3      1        66.7
search    2      0        100.0

Такая выборка сразу показывает, куда направить усилия: модуль cart пропускает в продакшен половину своих дефектов. Это и есть работа с метриками — не отчётность ради отчётности, а решение о том, где усилить тестирование.

Вредные метрики, о которых полезно сказать: число найденных багов на тестировщика (поощряет заведение мусорных дефектов и дробление одного бага на пять), процент автоматизации как самоцель, покрытие кода 100% — все они измеряют активность, а не качество, и быстро начинают деформировать поведение команды.

Типичные ошибки кандидатов

Смешивают load и stress: первое — про ожидаемую нагрузку, второе — про поиск предела.
Оперируют средним временем ответа вместо перцентилей.
Обещают «протестировать безопасность» без согласования и на продакшене.
Называют метрикой качества количество заведённых багов.
Не могут объяснить, что делать с полученной метрикой, — цифра без решения бесполезна.

Как ответить кратко

Нагрузочное тестирование делится по цели: load — ожидаемая нагрузка и соответствие SLA, stress — рост до отказа и характер деградации, spike — резкий всплеск, soak — длительная работа и утечки памяти, scalability — эффект от добавления ресурсов. Смотрю RPS, долю ошибок и время ответа в перцентилях p95 и p99, а не среднее. По безопасности как функциональный тестировщик проверяю права доступа и IDOR, инвалидацию сессии, базовые XSS и SQL-инъекции, утечку лишних полей и чувствительных данных в логах и URL — только на тестовых стендах и по согласованию. Из метрик считаю полезными DDP, число дефектов, ушедших в продакшен, плотность дефектов по модулям и время до исправления; вредными — количество багов на тестировщика и процент автоматизации как самоцель.