Три подхода к нагрузочному тестированию «1С»: практический опыт IBS

Нагрузочное тестирование (НТ) проводится с разными целями и на разных этапах проекта — как до старта эксплуатации, так и после запуска системы. В этой статье команда IBS на примере реальных кейсов расскажет, на что стоит обратить внимание в каждом случае.

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

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

В случае «1С» НТ обычно проводится при количестве пользователей системы от 50 до 2000. Ниже этого предела тесты возможны, но носят специфический характер. В них речь идет больше о скорости работы конкретных операций и меньше о параллельности работы всей системы. Тестирование систем с числом пользователей более 2000 чаще всего относится к маркетинговым или исследовательским мероприятиям. Если же они проводятся в интересах реального внедрения, все равно имеют уникальный для каждого тестирования жизненный цикл, причем достаточно длительный по времени. В этой статье речь пойдет о типовых ситуациях.

Рассказывает Евгений Филиппов, эксперт отделения 1С-разработки IBS

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

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

Узкие места со стороны заказчика — низкая вовлеченность в проект, поздняя готовность инфраструктуры, нехватка дискового пространства, сложности с согласованием доступов и т. п. Все эти задачи тоже проще решать, находясь непосредственно на объекте.

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

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

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

Между первым и вторым отчетным тестом должно быть примерно 3-4 недели, чтобы за это время успеть исправить критические замечания по первому тесту. Они могут касаться прикладного решения, качества и количества данных, оборудования, системы лицензирования и т. д.

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

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

Рассказывает Елена Маламут, руководитель проектов IBS

В задачи нашей команды входило тестирование систем «1С:УХ» и «1С:MDM» для крупной компании в сфере телекоммуникаций. Для первой системы было проведено 18 нагрузочных тестов, в том числе интеграционных. Все они выполнялись на фоне типовой нагрузки, имитирующей стандартную работу около 500 пользователей. Во второй системе объем тестов был меньше, при этом шел большой поток внешней информации, в том числе активное взаимодействие с «1С:УХ».

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

Главное преимущество НТ в период ОПЭ — акцент на конкретных проверках производительности. Кроме того, к этому времени уже есть рабочая база с данными, а функциональность системы близка к продуктивной. Тестирование становится максимально приближенным к реальной эксплуатации.

Однако есть и минусы. При каждом обновлении версии системы из-за правок функциональности приходится актуализировать или полностью перезаписывать скрипты. К тому же стенд не всегда находится в монопольном пользовании команды НТ.

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

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

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

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

Рассказывает Марат Невмянов, заместитель директора отделения нагрузочного тестирования IBS

Мы проводили независимое нагрузочное тестирование «1С:ERP 2.0» в крупной промышленной компании. Необходимость в нем возникла, когда выяснилось, что фактические показатели системы не соответствуют требованиям SLA. Это стало ясно, когда в ней начали работать первые пользователи.

Нам нужно было проверить поведение системы под нагрузкой, предложить меры для повышения производительности и определить рекомендуемую конфигурацию для будущего масштабирования. Кроме того, в этот момент компания переходила с Ubuntu на Astra Linux, поэтому требовалось убедиться в стабильной работе решения на новой ОС. Все задачи предстояло решить в сжатые сроки, так как система уже находилась в промышленной эксплуатации.

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

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

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

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

НТ обязательно, если:

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

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