Как разработчики мы понимаем, что даже лучшие решения могут столкнуться с проблемами при увеличении нагрузки, поэтому важно заранее оценить их устойчивость и работоспособность. В этой статье я рассмотрю принципы нагрузочного тестирования в 1С, поделюсь методами построения обработок, а также покажу, как правильно запускать тесты, интерпретировать их результаты и фиксить ошибки.
Привет, Хабр! Меня зовут Дарья Бавыкина, я разработчик IBS. На производительности 1С могут сказаться и обновление платформы до последней версии, и внедрение новых функций, и внесение каких-либо, порой даже мельчайших, изменений в конфигурацию. Чтобы бизнес-заказчик не поседел от ужаса, когда его главная учетная система начнет зависать посреди рабочего дня, после любых «телодвижений» разработчиков важно проводить нагрузочное тестирование. Ниже — подробная инструкция как.
Установка расширения Тест-центр и подготовка к тестированию
Для моделирования и автоматизации многопользовательских нагрузочных испытаний в 1С есть специальный инструмент — Тест-центр. Это расширение входит в продукт «1С:Корпоративный инструментальный пакет». С его помощью можно управлять процессом тестирования и оценивать производительность и масштабируемость конфигурации в реальных условиях.
Дерево расширения выглядит следующим образом:
Для тестирования информационной базы необходимо объединить конфигурацию Тест-центра с конфигурацией тестируемой базы при помощи операции сравнения и объединения конфигураций. В результате объединения к метаданным тестируемой базы будут добавлены объекты и общие модули, необходимые для работы Тест-центра.
После установки расширения нам необходимо сгенерировать данные, на которых будет проводится тестирование. Поскольку тесты имеет смысл проводить на достаточно большом объеме различных данных, этот подготовительный этап обычно занимает немало времени. Данные генерируются в зависимости от профиля тестирования и от условий проведения теста. Как вариант, тестирование можно проводить на копии реальной базы данных.
Анализ профиля тестирования мы, как правило, делаем исходя из вводных заказчика о его стандартной работе в системе. Например, если мы знаем, что у клиента за сутки проводится 1 миллион документов, то, исходя из этого, и рассчитываем, сколько у нас должно быть итераций теста, сколько виртуальных рабочих мест и так далее. Параметры при этом подбираются постепенно: мы запускаем тест, скажем, на 10 пользователях, анализируем количество созданных документов и при необходимости поэтапно увеличиваем нагрузку. Также на этапе анализа профиля тестирования нам важно понять, где будут проводиться тестовые действия — на клиенте или на сервере. Например, формирование документов будет происходить в пользовательском режиме, а если нам необходимо протестировать какие-то моменты, связанные с интеграцией, то это будет происходить уже на сервере.
Строение обработок
Каждое тестовое действие, автоматически выполняемое виртуальным пользователем, должно быть предварительно запрограммировано в виде тестовой обработки. Добавив в нашу конфигурацию расширение Тест-центра, мы увидим в дереве ее шаблон:
У шаблона тестовой обратки есть форма, с которой мы будем работать и которую в дальнейшем будем править уже под наши нужды, то есть под наш профиль тестирования:
В модуле формы тестовой обработки есть свои методы, которые мы также будем настраивать под себя:
Чтобы создать собственную кастомную обработку на основе тестовой обработки из шаблона, нам необходимо вынести на форму ряд параметров, таких как пауза между сценариями (пейсинг) и пауза между операциями, а также несколько реквизитов:
Собрав все необходимые реквизиты на форме, мы можем приступать непосредственно к написанию самого теста. Рассмотрим, какие для этого существуют методы.
1. Метод «Инициализировать».
Необходим для единовременной подготовки данных перед выполнением теста. В этом методе мы объявляем переменные, объявляем генераторы и делаем замеры, чтобы в дальнейшем понять, сколько времени у нас заняла инициализация теста.
2. Метод «Инициализировать параметры на сервере».
Необходим для единовременной инициализации всех переменных, реквизитов и таблиц значения, которые мы будем использовать в нашем тесте. На примере ниже я вызвала методы, которые заполняют организации, способы отражения сотрудника, а также заполнила реквизит «ВалютаДокумента»:
3. Метод «Инициализировать очередь».
Необходим для объявления желаемой последовательности выполнения методов в ходе тестирования. На примере ниже мы видим, что сначала у нас произойдет первое открытие форм, затем пауза по номеру виртуальных рабочих мест (ВРМ), сброс на начало, замер времени, запуск нашего основного метода полезной нагрузки — «СформироватьОтражениеЗарплатыВБухучете», конец замера времени и снова сброс на начало:
4. Метод «Выполнить шаг теста».
Необходим для прохождения очереди выполнения, которую мы объявили в предыдущем методе. Также здесь мы можем выполнять запросы и при необходимости производить замеры производительности.
5. Метод «Выполнить шаг теста действие».
Необходим для вызова всех методов, которые были сформированы в очереди выполнения шагов теста:
6. Метод формирования документа.
В моем примере метод полезной нагрузки назван «СформироватьОтражениеЗарплатыВБухучете». Здесь мы начинаем замер — отдельный по каждому из формируемых документов — здесь же объявляется время начала, время окончания и вычисляется общая длительность теста. Также мы сообщаем пользователю о том, что в данный момент у нас происходит выполнение какого-то шага теста, и заполняем все реквизиты на форме:
По окончании замера мы должны отправить запрос в базу данных InfluxDB. Для этого мы вызываем метод «Выполнить запрос» (кастомная доработка IBS, вы можете создать свою) и указываем название осуществленного действия — «СформироватьОтражениеЗарплатыВБухучете». Если бы кроме отражения зарплаты мы бы захотели сформировать еще какой-то документ, например, реализацию товаров и услуг, то в базу данных нужно было бы отправить дополнительный запрос о создании документа реализации товаров и услуг, со своим замером времени, длительностью и успешностью выполнения.
Запуск обработок. Работа теста
Вся основная работа происходит в пользовательском режиме в расширении Тест-центра. В окне создания нового сценария мы задаем его название и добавляем в табличную часть структуру — роль (из соответствующего справочника Тест-центра), пользователя, клиента и количество итераций. И здесь же выбирается обработка как элемент справочника «Обработки», который также необходимо создать в конфигураторе, а затем выбрать из выпадающего списка. Предупреждение: выбирайте внутреннюю обработку, так как внешняя обработка работает некорректно.
Добавление элементов в справочники Тест-центра «Сценарии», «Роли» и «Обработки»:
Добавив новую обработку, мы можем ее настроить. Именно здесь мы заполняем ту самую форму, которую создавали ранее в конфигураторе. Вводим пейсинг, число итераций, паузу на старте, паузу, даты документов и ФИО.
Следующий шаг — создаем пользователя Тест-центра. Для этого выбираем из выпадающего списка нужное нам имя из справочника пользователей основной конфигурации и вводим пароль для запуска виртуального рабочего места:
Далее создаем клиента тестирования. Здесь все просто — выбираем тип клиента «Тонкий», остальные поля заполнятся автоматически.
Нам остается только заполнить количество виртуальных рабочих мест. В моем сценарии их три.
Следующий пункт — настройка ограничений сценария:
К сожалению, никакого секрета здесь нет — подобрать правильные ограничения с первого раза практически невозможно. Это одна из тех вещей, которые можно выяснить только опытным путем. Если, например, мы заметим, что тест отвалился на моменте подготовки, то мы вернемся и увеличим количество секунд таймаута подготовки. Также тайм-ауты придется продлить, если мы захотим увеличить количество виртуальных рабочих мест или число итераций теста.
Сценарий создан — нужно его запустить. Для этого открываем справочник «Агенты». Для удобства и корректной работы я советую его выгрузить, после чего нажать на кнопку «Включить режим агента». Тест-центр немного зависнет подумает и создаст нового агента в текущем сеансе.
Только после этого мы можем запустить наш тест. Для этого возвращаемся в справочник сценариев, выбираем тест в таблице значений и жмем «Выполнить». Перед нами открывается окно «Состояние теста»:
В этом окне отражены пять этапов тестирования: подготовка, инициализация, выполнение, запись результатов и удаление данных. Также мы видим количество виртуальных рабочих мест, видим, сколько из них запущено в текущий момент, какая у нас текущая итерация и сколько в ней было выявлено ошибок. Здесь же мы видим, как наши виртуальные рабочие места запускаются в режиме реального времени.
В стартовом окне ВРМ собраны ключевые параметры подключения: имя пользователя, компьютер, порт, номер сессии, номер виртуального рабочего места и выполняемая роль.
Теперь переключаемся на окно нашей полезной нагрузки — «Отражение зарплаты в бухучете». Смотрим, что документ записался успешно и никаких ошибок обнаружено не было.
Мой совет: на первых этапах, в принципе, когда мы проводим какой-то тест и не запускаем его на больших нагрузках, не стоит закрывать форму объекта. Даже если тест пройдет успешно, система может пропустить сообщение и по факту не создать документ. Такие вещи можно, конечно, отслеживать и по журналу регистрации, но, мне кажется, при небольшом количестве итераций и виртуальных рабочих мест гораздо проще делать это вручную — в уже открытом окне.
Результат теста и его анализ
Вне зависимости от успешности теста после его завершения перед нами автоматически открывается окно с результатами. В нем собрана информация по нашему сценарию и указано, был ли тест прерван:
Для нас самая интересная вкладка — это «Протокол», то есть детализация ошибок по журналу регистрации.
По каждому виртуальному рабочему месту в протоколе указаны проделанные шаги, замеры времени и длительности операций. Как видим, тест завершился успешно.
Результаты тестирования можно проанализировать не только через журнал регистрации, но и с помощью системы визуализации данных, таких как Grafana. Для наглядности я сделала скриншот по итогам другого большого теста с целым рядом различных обработок:
Как видим, два последних теста в данном случае были провалены.
Ту же самую статистику выполнения можно оценить и в графическом виде:
Распространенные ошибки и их решение
Ошибка Jenkins. Самая популярная и самая раздражающая ошибка. Как я сказала выше, если у вас на проекте не подключен Jenkins, эта ошибка будет вылезать постоянно, нужно просто научиться ее игнорировать.
Ошибка конфликта блокировок. Возникает в том случае, если в коде закралась ошибка, которую консультант не словил в процессе ручного тестирования. Идем фиксить код.
Ошибка разработки теста. Появляется при запуске некорректно написанного теста. Анализируем ошибку в журнале регистрации и правим тест.
Ошибка теста после обновления. Самая неприятная ошибка: у нас был хороший работающий тест, мы накатили обновление — и все сломалось. Такое бывает, например, когда разработчики делают в каком-то документе, который мы используем для тестирования, определенный реквизит обязательным, после чего наш документ перестает проводиться. Это также отслеживается путем анализа журнала регистрации после выполнения теста.
Нехватка прав у пользователей. Смотрим в журнале регистрации, под какими ВРМ каких прав не хватает, добавляем их и перезапускаем тест.
Заключение, или Преимущества нагрузочного тестирования
Хотя процесс нагрузочного тестирования может казаться несколько скучным, пропускать этот этап никак нельзя. По результатам тестирования можно выявить узкие места на ранних этапах разработки, понять, что необходимо изменить как в самой информационной системе, так и в «железе», внести корректировки и таким образом предотвратить простои, оптимизировать ресурсы и улучшить пользовательский опыт. Нагрузочное тестирование — залог надежности и стабильности бизнес-приложений. Так что хочешь не хочешь, а придется засучить рукава, открыть Тест-центр и запустить свою обработку.
