Развёртывание LMS в выделенном облаке или во внутреннем контуре заказчика даёт компании контроль над инфраструктурой, данными и правилами эксплуатации. При этом каждый проект обладает собственной конфигурацией: на работу системы влияют вычислительные ресурсы, сеть, хранилища, балансировка нагрузки, настройки среды оркестрации и подключённые компоненты.
Поэтому при внедрении Эквио в выделенном облаке или внутреннем контуре нагрузочное тестирование становится обязательной контрольной точкой перед вводом системы в промышленную эксплуатацию. Оно подтверждает, что конкретная развернутая среда способна поддерживать согласованный типовой профиль пользовательской активности.
Зачем нагрузочное тестирование бизнесу
Производительность LMS нельзя оценить только по заявленным характеристикам серверов. Даже при одинаковой версии платформы итоговое поведение системы зависит от того, как устроен конкретный контур заказчика: сколько ресурсов выделено сервисам, как настроена сеть, какие механизмы используются для хранения контента, логирования и мониторинга.
Нагрузочное тестирование переводит вопрос о готовности системы из области предположений в область измеримых результатов. До запуска в продуктивную эксплуатацию команда проверяет работу платформы при согласованном количестве пользователей, фиксирует время отклика, интенсивность запросов, ошибки, состояние инфраструктуры и признаки деградации компонентов.
Для бизнеса это означает более предсказуемый запуск обучения. Для ИТ-команды — возможность заранее проверить соответствие инфраструктуры требованиям, выявить потенциальные ограничения и устранить их до того, как в системе начнут работать сотрудники.
Важно, что типовое нагрузочное тестирование Эквио подтверждает работоспособность в штатном пользовательском сценарии. Оно не моделирует любой возможный кратковременный всплеск — например, ситуацию, когда значительно большая доля сотрудников одновременно начинает проходить один курс или тест. Если заказчику требуется проверить особый массовый сценарий, он должен быть отдельно определён в требованиях и проверен по отдельному профилю нагрузки.
Когда проводится нагрузочное тестирование
Нагрузочное тестирование — часть процесса внедрения Эквио при развёртывании в выделенном облаке или внутреннем контуре заказчика. Исключение составляют развертывания по схеме LTS — Long Time Support.
Проверка начинается после того, как команда DevOps завершила развертывание инфраструктуры, а базовая работоспособность системы подтверждена smoke-тестированием. На этом этапе LMS уже доступна, но её поведение при параллельной пользовательской активности необходимо подтвердить на фактической инфраструктуре заказчика.
До начала работ команды внедрения, QA и DevOps согласуют дату и время прогона. Команда QA получает параметры окружения: информацию о виртуальных машинах и их ресурсах, количестве активных пользователей, адресах сервисов, доступах к LMS и системам мониторинга. Если административная часть платформы доступна только из защищённого контура, для тестирования организуется подключение через VPN.
Затем в LMS создаются тестовая компания, необходимое число активных пользователей, учебные материалы и назначения. Для проверки применяются синтетические учётные записи и тестовый контент, поэтому для проведения работ не требуется использовать персональные данные сотрудников заказчика.
Убедитесь в надежности LMS в деле
Как Эквио формирует нагрузку при тестировании
Тестирование не сводится к генерации произвольного количества HTTP-запросов. Команда QA использует стандартизированный сценарий, который воспроизводит типовые действия пользователей в Эквио. Такой подход обеспечивает сопоставимость проверок и помогает оценивать работу не отдельного API-метода, а сквозного пользовательского пути.
Автоматизированные сценарии имитируют:
- получение программ обучения и данных о прогрессе;
- открытие и прохождение учебных материалов;
- загрузку PDF-материалов из S3-совместимого объектного хранилища;
- работу с разделом «Информация»;
- получение списка тестов и опросов, прохождение тестирования;
- отправку статистики и результатов обучения;
- служебные обращения, необходимые для корректной навигации и отображения данных в приложении.
Сценарии составлены на основе анализа реального поведения пользователей на действующих окружениях. Отдельные действия выполняются в разных сочетаниях, а их количественное распределение соответствует принятому профилю нагрузки.
При определении ожидаемой одновременной активности используется типовой ориентир: около 1% от общего количества пользователей платформы. Это не универсальная константа для всех организаций, а исходное допущение для штатного сценария, которое подтверждается на конкретном проекте.

Пример нагрузочного теста Эквио. Система моделирует одновременную работу 100 виртуальных пользователей. В ходе теста команда отслеживает интенсивность запросов, время ответа системы и количество ошибок.
Что контролирует команда QA
Нагрузка поддерживается в течение 30–60 минут. За это время команда QA отслеживает не только ответ системы на пользовательские действия, но и работу всей технической среды.
В ходе прогона контролируются:
- количество одновременных виртуальных пользователей;
- интенсивность запросов — RPS и RPM;
- медианное и перцентильное время ответа, включая p99;
- доля неуспешных запросов, ошибки и исключения;
- загрузка CPU и RAM;
- сетевые показатели;
- состояние очередей и взаимодействие компонентов;
- признаки деградации и утечек памяти при продолжительной нагрузке.
Для генерации нагрузки используется фреймворк Locust. Наблюдение за техническим состоянием среды выполняется с помощью систем мониторинга и журналирования; в зависимости от контура применяются, в частности, Prometheus, VictoriaMetrics и Kibana.
Важно корректно интерпретировать метрики. В типовом профиле учитывается нагрузка, создаваемая пользовательскими действиями в LMS. Интеграционные запросы и обращения из административной панели в этот расчёт не входят: они должны оцениваться отдельно, если являются существенной частью целевой архитектуры заказчика.

Мониторинг нагрузки на сервер во время тестирования. Рост показателей на графике соответствует началу нагрузочного теста: команда наблюдает, как инфраструктура реагирует на активность виртуальных пользователей и как меняется потребление ресурсов под нагрузкой.
Что происходит после теста
Нагрузочное тестирование не является формальной процедурой «сдал или не сдал». Его цель — заранее обнаружить факторы, которые могут ограничить производительность в конкретной инфраструктуре, и устранить их до ввода системы в эксплуатацию.
Если согласованные параметры не достигнуты или мониторинг показывает узкое место, команда QA фиксирует результаты и передаёт их DevOps-специалистам. После корректировки инфраструктурной конфигурации проводится повторная проверка. Так команда подтверждает, что внесённые изменения устранили причину деградации, а не только временно улучшили отдельную метрику.
Ограничение может быть связано с доступными ресурсами виртуальных машин, сетевой связностью компонентов, параметрами хранилища, очередями, балансировкой нагрузки или другими настройками среды. Проверка помогает локализовать источник проблемы на основе измерений и выбрать обоснованное решение.
По итогам работ команда QA готовит протокол нагрузочного тестирования. В нём фиксируются параметры окружения, заявленные требования, состав сценариев, метрики, статистика запросов и ошибок, а также вывод о соответствии системы согласованным условиям. Отчёт передаётся заказчику через команду внедрения.
Контроль производительности после релизов
Нагрузочное тестирование Эквио применяется не только при развёртывании у заказчика. Команда также проводит проверки на тестовом окружении после изменений платформы, чтобы отслеживать, не ухудшилась ли производительность после добавления новой функциональности или обновления компонентов.
Для этого используется сопоставимый типовой пользовательский сценарий. Он позволяет сравнивать версии в одинаковых условиях и выявлять регрессии: увеличение времени ответа, снижение пропускной способности, рост числа ошибок, повышенное потребление ресурсов или потерю устойчивости при продолжительной нагрузке.
Этот результат не является гарантией идентичной производительности в любом клиентском контуре. На показатели влияют конфигурация инфраструктуры, версия и состав компонентов, сеть, объём и тип контента, настройки журналирования, профиль активности пользователей и интеграции. Однако регулярные сопоставимые прогоны позволяют команде обнаруживать ухудшения до поставки релиза и вносить оптимизации до того, как изменения попадут в рабочие окружения.
Какие результаты получает заказчик
Подход Эквио к нагрузочному тестированию отличают несколько особенностей:
- проверка проводится не на абстрактном стенде, а на фактической инфраструктуре заказчика — после реального развёртывания, а не по документации на «железо»;
- сценарии нагрузки построены на анализе реального поведения пользователей Эквио, а не на случайной генерации запросов;
- для тестирования не нужны персональные данные сотрудников заказчика — используются синтетические учётные записи;
- по итогам заказчик получает не вывод «прошло / не прошло», а протокол с конкретными метриками, на основании которого можно принимать инфраструктурные решения;
- проверка производительности повторяется и после релизов платформы, что позволяет ловить регрессии до того, как они дойдут до продуктивной среды заказчика.
Нагрузочное тестирование даёт бизнесу и ИТ-команде единый, измеримый ответ на вопрос о готовности LMS: соответствует ли конкретная инфраструктура согласованному штатному сценарию использования и сохраняет ли платформа ожидаемый уровень производительности после развития продукта.
Готовы протестировать Эквио на своих задачах?
Частые вопросы о нагрузочном тестировании Эквио
Сколько длится нагрузочное тестирование Эквио?
Нагрузка поддерживается 30–60 минут, в течение которых команда QA отслеживает поведение платформы и состояние инфраструктуры.
Нужны ли для теста персональные данные сотрудников заказчика?
Нет. Тестирование проводится на синтетических учётных записях и тестовом контенте, созданных в тестовой компании внутри LMS.
Что если инфраструктура не проходит согласованные параметры?
Команда QA фиксирует узкое место и передаёт результаты DevOps-специалистам; после корректировки конфигурации тестирование повторяется, чтобы подтвердить, что причина деградации устранена.
Какой инструмент используется для генерации нагрузки?
Фреймворк Locust; состояние инфраструктуры при этом наблюдается через Prometheus, VictoriaMetrics и Kibana — набор зависит от конкретного контура.
Что заказчик получает по итогам тестирования?
Протокол нагрузочного тестирования: параметры окружения, состав сценариев, метрики, статистику запросов и ошибок, а также вывод о соответствии системы согласованным условиям.
Автор:
Константин Савченко — эксперт в сфере маркетинга и корпоративного обучения персонала






