Нагрузочное тестирование 1С:ERP. УХ: как подтвердить готовность системы к работе 500 пользователей

Внедрение 1С:ERP обходится в десятки миллионов рублей. Но 80% эффекта от внедрения уничтожаются, если в день пиковой нагрузки система «тормозит» на критически важных операциях.

Нагрузочное тестирование — это не дополнительная ИТ-активность. Это страховка бюджета внедрения и репутации бизнеса. Его задача — не просто измерить скорость работы системы, а подтвердить, что выбранная архитектура, оборудование и программная конфигурация обеспечат стабильную работу бизнеса после запуска.

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

Зачем бизнесу нагрузочное тестирование

Для руководителей компаний нагрузочное тестирование — это инструмент снижения проектных и операционных рисков.

Оно позволяет еще до ввода системы в промышленную эксплуатацию получить ответы на принципиальные вопросы:

• выдержит ли система планируемое количество пользователей;

• достаточно ли выбранной серверной инфраструктуры или потребуется ее расширение;

• сохранится ли требуемая производительность при росте бизнеса;

• существуют ли скрытые узкие места, которые приведут к деградации работы уже после запуска.

За каждым из этих вопросов стоят прямые потери:

• простой сотрудников при ожидании — 500 человек х 3 000 руб/час (возьмем для примера среднюю стоимость 1С-разработчика Middle уровня) = 1 500 000 руб/час.

• просрочки при формировании отчетности, расчете налогов и выплате зарплаты — штрафы со стороны контролирующих органов.

• экстренная закупка серверов после запуска — незапланированное увеличение бюджета на 30-50%.

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

В рассматриваемом проекте тестирование должно было подтвердить готовность системы к одновременной работе около 500 пользователей в одном узле, а также способность системы сохранять стабильную производительность при увеличении нагрузки, объема данных и числа одновременно работающих сотрудников.

Дополнительно проверялось соответствие требованиям по доступности, отказоустойчивости, масштабируемости и сохранению производительности после установки обновлений и развития функциональности. 

Одним из критериев качества являлась оценка пользовательского опыта по методике APDEX не ниже уровня «Хорошо». На момент проведения испытаний система также не должна была содержать ошибок, способных привести к падению клиентской или серверной части.

Какие показатели оценивались

В отличие от обычного тестирования производительности, где часто анализируется только время выполнения отдельных операций, для корпоративной ERP-системы важно оценивать работу всего комплекса.

В качестве исходных параметров использовались характеристики будущей эксплуатации системы:

• общее количество пользователей;

• число одновременно работающих пользователей;

• объем документов, создаваемых ежемесячно;

• количество объектов учета — основных средств, сотрудников, видов расчетов и других справочных данных.

Основной интегральной оценкой качества работы системы был выбран показатель APDEX (Application Performance Index), который отражает удовлетворенность пользователей скоростью выполнения операций.

Дополнительно на протяжении всего тестирования собирались инфраструктурные метрики:

• загрузка процессоров по каждому ядру и очередь к CPU;

• использование оперативной памяти и интенсивность обмена;

• скорость чтения и записи дисковой подсистемы, длина очередей и задержки операций ввода-вывода.

Такой подход позволял не только определить, насколько быстро выполняются бизнес-операции, но и установить причины возможного снижения производительности.

Исходные условия тестирования

Испытания проводились непосредственно на оборудовании заказчика, что позволяло максимально приблизить условия тестирования к будущей промышленной эксплуатации.

Тестовая база была подготовлена таким образом, чтобы обеспечить одновременную работу до 500 пользователей. Отказоустойчивость системы обеспечивалась резервированием серверов приложений и СУБД, а целевой сценарий масштабирования также предусматривал эксплуатацию системой 500 пользователей.

Ключевым требованием являлось создание реалистичной нагрузки, максимально соответствующей повседневной работе пользователей после ввода системы в эксплуатацию.

Как строилось нагрузочное тестирование

На первом этапе специалисты совместно с заказчиком определили перечень наиболее важных пользовательских операций и сформировали сценарии тестирования. Затем были подготовлены требования к системному ландшафту, развернута тестовая инфраструктура, утверждена программная архитектура, настроено программное и аппаратное обеспечение, выполнено первоначальное заполнение базы данных и организован сбор диагностической информации.

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

После этого система последовательно испытывалась при нагрузке 100, 200, 300 и 500 одновременно работающих пользователей. Такой поэтапный подход позволял оценить, как изменяется производительность по мере роста нагрузки и насколько линейно масштабируется решение.

В общей сложности подготовка к нагрузочному тестированию заняла около 2 недель, а сами тесты — неделю.

Как создавалась нагрузка

Для моделирования работы пользователей использовался 1С:Тест-центр, входящий в состав 1С:Корпоративного инструментального пакета.

Инструмент запускал виртуальные рабочие места (ВРМ), каждое из которых полностью имитировало работу реального пользователя. Виртуальные пользователи последовательно выполняли заранее подготовленные бизнес-операции: открывали документы, копировали их, проводили, запускали обработки и выполняли другие действия, характерные для ежедневной эксплуатации системы.

Управление всем процессом осуществлялось с отдельного рабочего места агента тестирования. Здесь был настроен перечень виртуальных пользователей с учетными данными, выполнялся запуск необходимого количества ВРМ, распределялись сценарии между группами пользователей и собирались итоговые результаты испытаний.

Каждая бизнес-операция была реализована в виде отдельной тестовой обработки — специализированной процедуры, выполняющей строго определенное действие. Такой подход обеспечивал воспроизводимость результатов и позволял точно измерять время выполнения каждой операции.

Особенностью использованной методики являлся динамический режим тестирования. После завершения очередной итерации виртуальный пользователь немедленно начинал следующую, без искусственных пауз между циклами. Благодаря этому нагрузка максимально соответствовала реальной эксплуатации, когда пользователи постоянно выполняют последовательность рабочих операций.

При этом справочная информация заранее загружалась в тестовую базу. Это позволяло исключить вспомогательные операции по созданию элементов справочников, которые не влияют на производительность исследуемых бизнес-процессов, но существенно усложняют сценарии тестирования.

Повторяемость результатов

Одним из важнейших требований нагрузочного тестирования являлась воспроизводимость результатов.

После завершения каждого тестового прогона все созданные в ходе испытаний документы автоматически удалялись. Благодаря этому каждый последующий запуск выполнялся при одинаковом исходном состоянии информационной базы.

Перед очисткой данных производился сбор всей статистики: подсчитывалось количество созданных объектов, фиксировалось время выполнения ключевых операций и рассчитывался показатель APDEX для каждого бизнес-сценария.

Такой подход позволял объективно сравнивать результаты различных итераций тестирования и оценивать влияние изменений в конфигурации или инфраструктуре.

Почему APDEX важен для бизнеса

В корпоративных проектах недостаточно знать, что операция выполняется, например, за две секунды. Руководителям важно понимать, насколько комфортно пользователям работать в системе.

Именно поэтому основным критерием оценки стал показатель APDEX — международная методика оценки удовлетворенности пользователей производительностью приложений.

Показатель рассчитывается по формуле:

APDEX(T) = (N + N₁ / 2) / N₀

где:

• T — целевое время выполнения операции;

• N — количество операций, завершившихся быстрее либо за время T;

• N₁ — количество операций, завершившихся за время от T до 4T;

• N₀ — общее количество выполненных операций.

Полученное значение интерпретируется следующим образом:

Использование APDEX позволяет перевести технические показатели в понятную для бизнеса метрику качества пользовательского опыта.

Что получил заказчик по итогам проекта

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

• четкое описание обнаруженных проблем производительности,

• заключение о причинах их возникновения,

• оценку потенциальных рисков

• рекомендации по их устранению.

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

Испытания подтвердили, что выбранная архитектура, программная конфигурация и инфраструктура обеспечивают стабильную работу системы при целевой нагрузке.

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

Вывод

Нагрузочное тестирование — это не финальная галочка в чек-листе внедрения информационной системы и не формальная проверка скорости ее работы. Это инструмент управления рисками.

С его помощью вы перестаете гадать — вы начинаете управлять производительностью как ресурсом:

• определяете, соответствует ли инфраструктура будущим нагрузкам

• выявляете потенциальные ограничения

• объективно оцениваете запас масштабируемости

• обеспечиваете прогнозируемую работу критически важных бизнес-процессов.

В результате вы получаете не только подтверждение текущей готовности системы, но и основу для принятия решений о дальнейшем развитии ИТ-ландшафта, модернизации инфраструктуры и масштабировании бизнеса без риска потери производительности.