Данные из 61вакансия · 12 августа 2026

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

Не «стань разработчиком за 3 месяца» — реальный путь входа на основе данных по 61 вакансия.

Мурадов ЮрийАвтор·Мурадов Юрий·Аналитик SkillStat
ДБПроверено·Денис Борисов·Технический редактор·Инженер по нагрузочному тестированию, performance QA
Junior-вакансий сейчас
8
13% от всех 61 вакансия
Сложность входа
Средняя
13% junior-вакансий
Senior / Junior+Intern
2.5x
На каждого junior+intern — 2.5 senior
Навыков / вакансия
15
медиана по вакансиям
Всего вакансий
61
активных в Москве
Можно ли с нуля Короткий план Roadmap Junior-рынок Портфолио Резюме Собеседование Ошибки Обучение FAQ

Можно ли стать инженером нагрузочного тестирования с нуля

Да. По данным SkillStat, 13% вакансий инженера нагрузочного тестирования — уровня junior или стажёр. Это 8 вакансий прямо сейчас.

«С нуля» у инженера нагрузочного тестирования редко значит буквально с нуля. Сюда приходят переходом — из функционального тестирования, эксплуатации или разработки, потому что нагрузочный тест без умения читать метрики системы под ним даёт красивый график и ноль выводов. Junior-позиций 8 из 61, медиана требований — 15 навыков, и половина списка про инфраструктуру, а не про генератор нагрузки.

Трудность в другом: здесь легко получить результат, которому нельзя верить. Запустил прогон, увидел время ответа, нарисовал график — и всё это ничего не значит, если данные были одни на всех виртуальных пользователей, база стояла пустая, а замер начался с холодного кэша. Ценность профессии не в прогоне, а во фразе «система держит столько-то при таких-то условиях, а дальше упирается вот сюда» — и в том, что эту фразу можно перепроверить.

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

Пять шагов от первого скрипта до отчёта, по которому команда принимает решение о релизе.

01
База под нагрузкой
HTTP и REST (57.4% вакансий инженера нагрузочного тестирования), SQL (65.6%), Linux (27.9%). Пока не понимаешь, что происходит между запросом и ответом, метрики не читаются.
02
Модель нагрузки
Сценарий, профиль пользователей, объём данных, длительность, критерии успеха. Это половина работы: прогон без модели — просто много запросов.
03
Инструмент
JMeter — в 31.1% вакансий. Учить надо не синтаксис, а пределы самого генератора: он умеет упереться раньше системы.
04
Метрики и узкое место
Grafana — в 39.3% вакансий инженера нагрузочного тестирования, Prometheus — в части. Связывай время ответа с базой, очередями, пулами соединений и контейнерами на одной шкале времени.
05
Отчёт
Условия, профиль, найденный предел, узкое место, рекомендация и границы вывода. Отчёт, который нельзя воспроизвести, стоит ноль.

Что учить инженеру нагрузочного тестирования первым

Не всё сразу. Вот очерёдность по частотности в вакансиях — от самого нужного к менее срочному.

Навык Все вакансии
Java 68.9%
SQL 65.6%
REST 57.4%
Git 50.8%
CI/CD 49.2%
Kubernetes 45.9%
Apache Kafka 44.3%
Microservices 41%
Jenkins 39.3%
Grafana 39.3%

«Все вакансии» — доля из 61 вакансия. Обновлено 12 августа 2026.

Полный список навыков с частотностью, связками и зарплатной премией — навыки инженера нагрузочного тестирования →

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

Порядок опирается на частотность навыков по данным вакансий. Первые 4–5 этапов — минимум для первого оффера.

  1. 01
    Основы тестирования

    Виды тестирования, тест-дизайн, тест-кейсы, баг-репорты — фундамент профессии.

  2. 02
    SQL 65.6% вакансий

    Проверка данных на уровне БД — без этого нельзя полноценно тестировать backend.

    Подробнее →
  3. 03
    API-тестирование 29.5% вакансий

    HTTP/REST, Postman, Swagger — тестирование backend-интерфейсов.

    Подробнее →
  4. 04
    Баг-трекинг и документирование 23% вакансий

    Jira, Confluence, TestRail — работа с задачами и тестовой документацией.

    Подробнее →
  5. 05
    Автоматизация тестирования

    Selenium, Playwright, PyTest — автоматизация регрессионных и e2e-тестов.

    Подробнее →
  6. 06
    CI/CD для тестов 39.3% вакансий middle+

    Интеграция тестов в пайплайн: запуск по PR, репорты, артефакты.

    Подробнее →
  7. 07
    Нагрузочное и безопасность middle+

    JMeter, k6, OWASP — производительность и базовые знания ИБ.

Junior-вакансии инженера нагрузочного тестирования: что реально требуют работодатели

Срез построен на 61 активных вакансия.

Junior-вакансий
8
inc. стажировки
Доля junior
13%
от всего рынка
Senior / Junior+Intern
2.5x
соотношение
Навыков / вакансия
15
медиана
Распределение вакансий по грейдам
Junior — 15.7% (8)
Middle — 45.1% (23)
Senior — 39.2% (20)
Что значат эти цифры. 8 вакансий уровня junior из 61 — вход умеренный. Рынок узкий по природе: нагрузочное тестирование заводят там, где отказ под пиком стоит денег, — банки, ритейл, телеком, крупные платформы. Такая команда не отдаёт новичку релизный замер. Практический вывод: целься не в вакансию «junior нагрузочное тестирование», а в функциональное QA или эксплуатацию в компании с настоящими пиками — нагрузка приедет к тебе сама.

Какие проекты сделать для портфолио

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

Нагрузочный кейс на своём стенде
Средняя · 1–2 недели
Стек: JMeter, Docker, Linux
GitHub: Репозиторий: скрипт, профиль нагрузки, конфигурация стенда в Docker Compose, README с условиями прогона
Ценность: Главный артефакт: JMeter — в 31.1% вакансий инженера нагрузочного тестирования, но ценность в модели, а не в скрипте
Ступенчатый профиль до отказа
Средняя · 1 неделя
Стек: JMeter, Grafana, Prometheus
GitHub: Отчёт: график ступеней, точка роста времени ответа, точка появления ошибок, вывод про предел
Ценность: Показывает главное умение: отличить деградацию от отказа и назвать предел числом
Разбор узкого места в базе
Средняя–высокая · 1–2 недели
Стек: PostgreSQL, SQL, Grafana
GitHub: Кейс: время ответа выросло, метрики базы под нагрузкой, найденная причина — блокировки или исчерпанный пул соединений
Ценность: SQL — в 65.6% вакансий, PostgreSQL — в 39.3%: чаще всего упирается именно сюда
Длительный прогон
Средняя · 3–5 дней плюс время прогона
Стек: JMeter, Grafana, Linux
GitHub: Отчёт по прогону на несколько часов: что менялось во времени — память, время ответа, ошибки
Ценность: Ловит то, чего не видно на коротком тесте: утечки и медленное накопление очереди
Регулярный прогон в пайплайне
Средняя · 3–5 дней
Стек: Jenkins, CI/CD, Git
GitHub: Конфигурация запуска, сохранение результатов прогонов, сравнение с прошлым замером
Ценность: CI/CD — в 49.2% вакансий, Jenkins — в 39.3%: нагрузка как регулярная проверка, а не разовый героизм

Как оформить GitHub и резюме

Профиль GitHub
  • Репозиторий с кейсом: скрипт, профиль нагрузки, конфигурация стенда и отчёт лежат рядом
  • Условия прогона в README обязательны: версия сервиса, объём данных, ресурсы стенда, длительность прогрева. Без них отчёт нечитаем
  • Графики — картинками в репозитории, рядом текст с выводом. Скриншот без вывода артефактом не считается
  • Скрипт выкладывай вместе с тестовыми данными: без них никто не поймёт, что генератор отправлял
  • Отдельный файл «границы вывода»: что тест не проверял и почему. Это и отличает инженера от человека с кнопкой «Пуск»
  • Дашборд Grafana — экспортом или скриншотами с подписями: какие метрики и почему именно они
Резюме без коммерческого опыта
  • Раздел «Проекты» вместо «Опыт работы»: кейс с моделью нагрузки описывается как рабочая задача
  • По каждому кейсу: сценарий, профиль, найденный предел, узкое место, что предложил менять
  • Навыки — только рабочие: Java, SQL. «Знаком с JMeter» без кейса читается как ноль
  • Опыт из функционального тестирования, эксплуатации или администрирования — половина ценности: напиши, что уже читал метрики и логи живой системы
  • Домен называй прямо: пики у банка, ритейла и телекома устроены по-разному, и второй вход проще в том же домене
Слабое резюме

«Изучил JMeter, умею создавать нагрузочные скрипты, знаком с Grafana и Linux»

Сильное резюме

«Собрал нагрузочный стенд сервиса заказов в Docker: профиль на 500 пользователей ступенями по 50, прогрев 10 минут, уникальные данные на каждого. Нашёл предел — время ответа росло с 300 пользователей, причина не в приложении: исчерпывался пул соединений к PostgreSQL, видно по Grafana. Отчёт с условиями воспроизведения и границами вывода: [ссылка]»

Самостоятельно, курсы или вуз — какой путь выбрать

Самостоятельно
Стенд поднимается в Docker на своём ноутбуке, инструменты бесплатны — тренироваться можно на собственном сервисе, который ты же и сломаешь нагрузкой
Ноутбук — плохая модель боевой системы: сеть, диски и соседние процессы врут, и часть выводов будет про твоё железо
Если рядом нет продукта с настоящими пиками, а HTTP, SQL и Linux уже не вызывают вопросов
Курсы с ментором
Разбор чужой модели нагрузки — то, чего нигде больше не увидишь: ошибки здесь не в скрипте, а в допущениях
Дорого, и программ по нагрузке мало: часть курсов — это JMeter за две недели и ноль про метрики системы
Если пришёл из функционального тестирования и упираешься не в инструмент, а в чтение метрик
Вуз / колледж
Сети, операционные системы, базы данных, архитектура — ровно та база, на которой держится анализ узких мест
Четыре года; нагрузочного тестирования в программе нет вообще, только фундамент под него
Если выбираешь первое образование и целишься в эксплуатацию, инфраструктуру или производительность
Ловушка нагрузочного тестирования: инструмент вместо модели. JMeter осваивается за две недели, и после этого кажется, что профессия взята. Но график ничего не стоит, пока не отвечено: сколько пользователей и почему столько, какие данные, сколько шёл прогрев, что происходило в базе в момент роста времени ответа. Инженера от кнопконажимателя отделяет один вопрос — «а можно этому результату верить?».

Что спрашивают на собеседовании

Модель нагрузки
Типовые вопросы
  • ·Как определишь профиль пользователей для незнакомого сервиса
  • ·Сколько виртуальных пользователей брать и откуда взялась цифра
  • ·Зачем нужен прогрев и что будет без него
  • ·Чем ступенчатый профиль отличается от пикового и когда какой
Как показать проектом

Кейс из портфолио: объясни, откуда взял профиль и данные

Метрики и анализ
Типовые вопросы
  • ·Почему среднее время ответа врёт и что смотреть вместо него
  • ·Время ответа выросло, а процессор свободен — где смотришь
  • ·Что показывает Grafana в момент деградации
  • ·Как отличить узкое место от симптома
Как показать проектом

Разбор узкого места: покажи графики и цепочку рассуждения

Система под нагрузкой
Типовые вопросы
  • ·Где чаще всего упирается: база, очередь, сеть, пул соединений
  • ·Что происходит с PostgreSQL при исчерпании пула соединений
  • ·Kafka копит отставание — о чём это говорит
  • ·Как ведёт себя сервис в Kubernetes при упоре в лимиты
Как показать проектом

Кейс с базой: покажи, чем подтвердил причину

Инструмент и его пределы
Типовые вопросы
  • ·Как понять, что упёрся генератор, а не система
  • ·Почему одни и те же данные на всех пользователей ломают тест
  • ·Как готовишь тестовые данные под прогон
  • ·Что происходит с памятью генератора на длинном прогоне
Как показать проектом

Скрипт из портфолио: покажи подготовку данных

Отчёт и выводы
Типовые вопросы
  • ·Что обязательно в отчёте, кроме графиков
  • ·Как формулируешь границы применимости вывода
  • ·Разработчик не согласен с выводом — твои действия
  • ·Прогоны на разных окружениях дали разное — что скажешь бизнесу
Как показать проектом

Отчёт из кейса: покажи раздел с условиями воспроизведения

Сколько времени нужно, чтобы стать инженером нагрузочного тестирования

Минимум
6–9 мес
Из функционального QA или эксплуатации: HTTP, SQL, Linux и метрики уже знакомы, добавляется модель нагрузки
Медиана
18–24 мес
С нуля, самостоятельно: сначала база и функциональное тестирование, потом нагрузка
Реалистично
24–36 мес
При совмещении с работой и без доступа к системе с настоящими пиками

Почему с нуля сюда долго. Нагрузочный тест — не отдельный навык, а надстройка. Сначала HTTP, SQL, Linux, логи, метрики и понимание архитектуры веб-приложения; инструмент поверх этого учится за две недели. Начавшие с инструмента застревают на месяцы: скрипты пишут, а объяснить, почему время ответа выросло, не могут.

Скорость решают три вещи: есть ли доступ к системе, которую можно нагрузить всерьёз; читаешь ли ты метрики регулярно, а не раз в месяц; есть ли рядом кто-то, кто спросит «а откуда ты взял этот профиль».

Ошибки новичков

Замер без прогрева

Почему мешает: Первые минуты прогона система разогревает кэши, пулы соединений и JVM. Цифры оттуда описывают холодный старт, а не рабочий режим — вывод получается про несуществующую систему

Как исправить: Прогрев — отдельной фазой, результаты за него в мусор. В отчёте отдельной строкой: сколько прогрев длился

Одни и те же данные на всех виртуальных пользователей

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

Как исправить: Уникальные данные на каждого: свой пользователь, своя корзина, свой диапазон запросов. Данные готовятся до прогона, а не внутри него

Смотрят на среднее время ответа

Почему мешает: Среднее прячет хвост: половина пользователей ждёт секунду, а те, кому плохо, ждут двадцать — и уходят именно они. Среднее по такому распределению не говорит ничего

Как исправить: p95 и p99 плюс распределение во времени. Среднее — только рядом с ними, никогда вместо

Генератор упирается сам в себя

Почему мешает: Процессор машины с генератором забит полностью, а вывод пишется про сервис. Самый обидный класс ошибок: тест измерил собственный ноутбук

Как исправить: Метрики машины-генератора — обязательная часть прогона. Упёрлись — раскидывай нагрузку по нескольким генераторам

Прогон на пустой базе

Почему мешает: На тысяче записей быстро всё. Проблемы начинаются на боевом объёме: планы запросов меняются, индексы перестают помогать, блокировки становятся видны

Как исправить: Наполни базу до реалистичного объёма до прогона. PostgreSQL — в 39.3% вакансий инженера нагрузочного тестирования именно поэтому

Отчёт без условий воспроизведения

Почему мешает: Через месяц никто, включая тебя, не вспомнит, какая была версия, сколько ресурсов у стенда, какой профиль и сколько шёл прогрев. Результат превращается в число без смысла и не сравнивается с новым замером

Как исправить: Условия — первый раздел отчёта: версия, окружение, ресурсы, профиль, данные, длительность, прогрев

Только график инструмента, без метрик системы

Почему мешает: Генератор показывает, что стало медленно. Он не показывает почему. Без Grafana (39.3% вакансий) и Prometheus вывод останется на уровне «сервис тормозит»

Как исправить: Метрики приложения, базы, очередей и контейнеров — на одной временной шкале с прогоном. Причина ищется по совпадению во времени

Сравнивают прогоны на разных окружениях

Почему мешает: Вчерашний замер на одном стенде, сегодняшний на другом — разница в цифрах не значит ничего, а вывод «после релиза стало хуже» уже ушёл в команду

Как исправить: Сравнение — только при одинаковых условиях. Изменилось окружение — прогоняй базовый замер заново

Как SkillStat считает данные

Источник: 61 вакансия в московском сегменте. Навыки и грейды извлекаются автоматически из текста каждой вакансии.

Грейды: определяются по требованиям вакансии — уровню опыта, упоминанию «junior», «intern», «стажёр». Это рыночная оценка объявления.

Сложность входа: рассчитывается по доле junior-вакансий и медиане навыков на junior-уровне. Это индикатор, а не гарантия.

Обновление: данные пересчитываются регулярно. Текущий срез — 12 августа 2026.

Частые вопросы

Можно ли стать инженером нагрузочного тестирования с нуля?
Формально да, junior-позиции есть: 8 из 61. Практически сюда почти всегда приходят переходом — из функционального тестирования, эксплуатации или разработки. Причина в устройстве работы: нагрузочный тест начинается там, где заканчивается понимание системы. Без HTTP, SQL, Linux и умения читать метрики прогон даёт график, а не вывод.
Чем нагрузочное тестирование отличается от функционального?
Вопросом. Функциональный тестировщик спрашивает «работает ли правильно», нагрузочный — «до какого момента работает и что происходит дальше». Отсюда другой стек: SQL (65.6% вакансий), Grafana (39.3%), Kubernetes (45.9%), Linux (27.9%) — искать надо не дефект в логике, а место, где система упирается.
Какой инструмент учить: JMeter, k6, Gatling или Locust?
JMeter — в 31.1% вакансий инженера нагрузочного тестирования, это самый частый в требованиях. k6, Gatling и Locust встречаются реже, но живы, и переход между ними занимает дни: модель нагрузки одна, меняется синтаксис. Начинай с JMeter ради рынка, помня, что инструмент — последнее, о чём спросят на собеседовании.
Нужно ли программировать?
На прикладном уровне. Java — в 68.9% вакансий инженера нагрузочного тестирования, Python — в 29.5%. Код нужен для скриптов генератора, подготовки данных, обработки результатов и чтения чужого сервиса, чтобы понять, где он тормозит. Писать продукт не придётся.
Нужен ли SQL?
Да, это самый частый навык профессии: 65.6% вакансий (40 из 61), PostgreSQL — в 39.3%. Под нагрузкой чаще всего упирается именно база: план запроса, блокировки, исчерпанный пул соединений. Нужны выборки, планы выполнения и метрики базы под давлением.
Зачем нужны Grafana и Prometheus?
Чтобы понять причину, а не только факт. Grafana — в 39.3% вакансий инженера нагрузочного тестирования, Prometheus — в части. Генератор показывает, что время ответа выросло; метрики системы показывают, что в тот же момент кончился пул соединений или выросла очередь. Причина ищется по совпадению во времени, и без общей шкалы её не видно.
Нужны ли Kubernetes и Docker?
Docker — в 34.4% вакансий инженера нагрузочного тестирования: на нём поднимается свой стенд, без которого учиться негде. Kubernetes — в 45.9%: это описание среды, где живёт нагружаемый сервис. Знать надо не администрирование, а то, как лимиты ресурсов и автомасштабирование меняют поведение системы под нагрузкой.
Что такое профиль нагрузки и зачем он?
Описание того, кто и что делает с системой: доля сценариев, интенсивность, длительность, объём данных, характер роста. Без профиля прогон превращается в отправку множества одинаковых запросов, а это не похоже ни на одну реальную ситуацию. Профиль берут из аналитики трафика, из пиков прошлого года или из прогноза бизнеса — и в отчёте всегда пишут, откуда он взят.
Что важнее: p95 или среднее время ответа?
p95 и p99. Среднее прячет хвост распределения: пока большинство получает ответ быстро, те, кому плохо, ждут в разы дольше — и уходят именно они. Вопрос про среднее задают почти на каждом собеседовании, и правильный ответ не «среднее плохое», а «покажи распределение и хвост».
Нужен ли Linux?
Да. Linux — в 27.9% вакансий инженера нагрузочного тестирования. Нужен, чтобы дойти до логов и метрик стенда самому: посмотреть загрузку, память, диски, открытые соединения, хвост лога во время прогона. Инженер, который просит цифры у DevOps, теряет половину времени и весь контекст.
Что показать в портфолио?
Один честный кейс: сценарий, профиль нагрузки, условия прогона, метрики системы, найденное узкое место, вывод и границы применимости. Используй ключевые навыки профессии: Java, SQL, REST. Пять скриншотов из инструмента без модели и условий хуже, чем один разбор на две страницы.
Сколько времени нужно, чтобы стать инженером нагрузочного тестирования?
Из функционального QA или эксплуатации — 6–9 месяцев: база уже есть, добавляется модель нагрузки и разбор метрик. С нуля, самостоятельно — 18–24 месяца, и бо́льшая часть срока уходит не на инструмент, а на HTTP, SQL, Linux и понимание архитектуры.
Где искать первую работу?
Там, где есть пики: банки, ритейл, телеком, маркетплейсы, крупные платформы. В компании без пиковой нагрузки роли просто нет. Смотри и смежные формулировки — тестирование производительности внутри команды разработки, эксплуатация, инженер по производительности. Сейчас на рынке 8 вакансий уровня junior.
Что спрашивают на собеседовании?
Модель нагрузки (откуда взял профиль, зачем прогрев), чтение метрик (почему среднее врёт, где упирается система), поведение базы и очередей под давлением, пределы самого генератора и структуру отчёта. Почти всегда просят разобрать свой кейс и защитить допущения. Подробнее — в разделе «Собеседование» на этой странице.
Сколько зарабатывает начинающий Инженер нагрузочного тестирования?
Ориентир для junior — 72 000–104 000 ₽ при медиане по профессии 160 000 ₽. Разбивка по грейдам и динамика — на странице зарплат инженера нагрузочного тестирования.
Где посмотреть навыки инженера нагрузочного тестирования?
На странице навыков инженера нагрузочного тестирования — частотность по 61 вакансия, разбивка по грейдам и связки инструментов.