В прошлом уроке мы разобрали, что нагрузка — одна из категорий, где manual QA замечает симптом, но диагностику узкого места отдаёт специалисту. Сейчас — подробнее про сам симптом: по каким конкретно цифрам можно понять, что продукт не справляется с нагрузкой, и откуда эти цифры вообще берутся.
Чему научишься за этот урок:
— называть три базовые метрики нагрузочного тестирования: latency, throughput, error rate;
— объяснять, зачем manual QA вообще смотреть на эти метрики, не проводя нагрузочное тестирование самому;
— ориентироваться, что JMeter — один из инструментов, которые генерируют такие отчёты (без деталей настройки);
— читать пример готового отчёта и определять, на каком уровне нагрузки релиз перестаёт проходить по метрикам.
Три метрики нагрузочного теста
Нагрузочное тестирование проверяет, как продукт ведёт себя не при одном пользователе, а при множестве одновременных запросов. Результат такой проверки описывают тремя базовыми метриками:
- Latency (задержка) — сколько времени проходит от отправки одного запроса до получения ответа на него. Измеряется в миллисекундах; чем меньше, тем быстрее отвечает система.
- Throughput (пропускная способность) — сколько запросов система успевает обработать за единицу времени (например, запросов в секунду). Чем больше, тем больше пользователей продукт способен обслужить одновременно.
- Error rate (доля ошибок) — какой процент запросов под нагрузкой завершился ошибкой вместо нормального ответа. В идеале при любой ожидаемой нагрузке этот показатель должен быть близок к нулю.
Кто проводит нагрузочное тестирование, а что делает manual QA
Manual QA, как правило, не проводит нагрузочное тестирование самостоятельно — это отдельная задача, которую выполняет более узкий специалист или специализированный автоматизированный инструмент, отправляющий множество запросов одновременно и замеряющий метрики выше. Один из известных инструментов, который умеет это делать и формировать отчёт по результатам, — JMeter. Мы не разбираем в этом курсе, как его устанавливать и настраивать (это тема отдельного продвинутого курса) — нам важно другое: manual QA должен уметь ВЗЯТЬ уже готовый отчёт (от JMeter или любого другого инструмента) и ПРОЧИТАТЬ его — понять, прошёл релиз по этим трём метрикам или нет. Это урок про интерпретацию данных, а не про инструмент.
Полезная аналогия: manual QA не обязан уметь чинить автомобиль, чтобы прочитать показания приборной панели и понять, что двигатель перегревается. Так же и здесь: не нужно уметь настраивать нагрузочный инструмент, чтобы прочитать его отчёт и понять, что система не справляется.
Пример: отчёт нагрузочного теста страницы оплаты
На нашей учебной платформе перед релизом провели нагрузочный тест страницы оплаты курса — той самой, через которую студент вводит данные и подтверждает покупку. Тест прогнали на четырёх уровнях нагрузки: 10, 50, 100 и 200 одновременных пользователей. Команда заранее договорилась о критерии: релиз проходит, если error rate не превышает 5% на всех уровнях нагрузки, ожидаемых в первую неделю после запуска (до 100 одновременных пользователей включительно).
Нагрузка (польз.) | Latency (ms) | Throughput (запр/сек) | Error rate ------------------- -------------- ------------------------ ----------- 10 120 80 0% 50 180 210 0.1% 100 420 240 2% 200 1350 190 18%
Как это читается: до 100 пользователей latency растёт, но остаётся в разумных пределах, throughput растёт вместе с нагрузкой, а error rate держится в пределах согласованного порога 5%. При 200 пользователях картина меняется резко: latency подскакивает более чем в 3 раза, throughput не просто перестаёт расти, а падает — система уже не успевает принимать столько запросов, а error rate взлетает до 18%, то есть почти каждый пятый запрос завершается ошибкой. Это и есть точка, где отчёт показывает: система не справляется с такой нагрузкой.
Итог:
— три метрики нагрузочного теста: latency (задержка одного ответа), throughput (запросов в единицу времени), error rate (доля ошибок под нагрузкой);
— manual QA не проводит нагрузочное тестирование сам — этим занимается специалист или инструмент вроде JMeter, — но должен уметь прочитать готовый отчёт и понять, прошёл ли релиз;
— в примере отчёта до 100 пользователей метрики в пределах согласованного порога, а при 200 пользователях error rate резко растёт до 18% и throughput падает — релиз по такому отчёту не проходит для нагрузки 200 пользователей.
Контрольный вопрос. Что измеряет метрика latency?
Подсказка: Latency — про задержку ОДНОГО запроса-ответа, а не про их количество или долю ошибок.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что измеряет метрика throughput?
Подсказка: Throughput — про объём обработки в единицу времени, а не про задержку одного запроса.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Согласно уроку, что обычно делает manual QA в отношении нагрузочного тестирования?
Подсказка: Урок явно разделяет «кто проводит тест» и «кто читает результат» — это разные роли.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. В примере отчёта из урока при нагрузке 200 одновременных пользователей throughput (пропускная способность) по сравнению со 100 пользователями:
Подсказка: Посмотри на числа throughput в таблице урока при 100 и при 200 пользователях.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Отчёт нагрузочного теста показывает: при 50 пользователях latency 180 ms и error rate 0.1%, а при 200 пользователях latency 1350 ms и error rate 18%. Какие выводы правильно сделать manual QA по этим данным (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Два варианта — это то, что прямо видно из чисел таблицы. Два других требуют экспертизы или полномочий, которых у manual QA нет (см. прошлый урок).
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется инструмент, упомянутый в уроке как пример известного инструмента, который генерирует отчёты нагрузочного тестирования? Ответь одним словом.
Подсказка: Название прямо указано в заголовке урока и в разделе про то, кто проводит нагрузочное тестирование.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. В отчёте нагрузочного теста колонка показывает, что при 100 одновременных пользователях 2% запросов завершились ошибкой вместо обычного ответа. Как называется метрика, которая описывает именно этот показатель? Ответь двумя словами на английском, как в уроке.
Подсказка: Речь про долю запросов, завершившихся ошибкой, а не про время ответа или количество запросов.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. В отчёте нагрузочного теста страницы оплаты курса из урока команда установила порог: релиз проходит, если error rate не превышает 5% на уровнях нагрузки до 100 пользователей включительно. На каком из протестированных уровней нагрузки error rate впервые превышает этот порог? Посмотри таблицу отчёта в уроке. Ответь одним числом.
Подсказка: Сравни значения error rate из таблицы урока на каждом уровне нагрузки с порогом 5%.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Объясни в 2-3 предложениях, почему manual QA полезно уметь читать отчёт нагрузочного теста, даже если он сам не проводит нагрузочное тестирование и не настраивает такие инструменты, как JMeter.
Критерий приёмки: объяснено, что нагрузочное тестирование выполняет отдельный специалист или инструмент, а не сам manual QA; указано, что задача manual QA — интерпретировать готовый отчёт по метрикам (latency/throughput/error rate) и определить, прошёл ли релиз по согласованным критериям; упомянуто, что это не требует умения настраивать сам инструмент.
Подсказка: Вспомни аналогию про приборную панель автомобиля из урока и общий критерий эскалации из прошлого урока.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. На нашей платформе перед релизом провели повторный нагрузочный тест страницы оплаты и получили другие цифры: при 10 пользователях latency 110 ms и error rate 0%; при 50 пользователях latency 160 ms и error rate 0.2%; при 100 пользователях latency 900 ms и error rate 9%; при 200 пользователях latency 2500 ms и error rate 31%. Используя тот же порог команды (error rate не должен превышать 5% на нагрузке до 100 пользователей включительно), определи, проходит ли этот релиз по критерию, и опиши, что тестировщик должен сделать дальше с этой находкой, не пытаясь сам настраивать нагрузочный инструмент или диагностировать причину.
Критерий приёмки: сделан вывод, что релиз НЕ проходит по критерию (error rate 9% на 100 пользователях превышает согласованный порог 5%); указано, что latency и error rate ухудшаются с ростом нагрузки на всех уровнях; описано, что тестировщик фиксирует находку с конкретными цифрами и эскалирует специалисту для диагностики причины (по общему критерию из прошлого урока — не хватает экспертизы для точной диагностики узкого места), не пытаясь сам настраивать инструмент или искать причину замедления.
Подсказка: Сначала сравни error rate на 100 пользователях с порогом 5%, затем вспомни общий критерий эскалации из прошлого урока — кто должен разбираться в причине замедления.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Мы разобрали три базовые метрики нагрузочного теста и научились читать готовый отчёт — не проводя тест самостоятельно и не настраивая инструменты вроде JMeter. Вместе с прошлым уроком это закрывает главу о безопасности и производительности: вы знаете, что тестировщик замечает и когда должен передать находку дальше. Дальше в курсе — глава «Управление тестовой деятельностью»: тест-план, критерии входа и выхода, риски продукта и проекта, мониторинг и итоговая отчётность.
