Умный учится на чужих ошибках. Эта статья — для умных тестировщиков 1C.
Привет, Хабр! Меня зовут Елена Маламут, я руководитель проектов по тестированию в IBS. В этой статье поделюсь с вами самым ценным — своей коллекцией факапов. Расскажу об ошибках из моего опыта, которые совершают на проектах по нагрузочному тестированию 1С.
Ошибка № 1. Не выделять отдельный стенд для нагрузочного тестирования
Выделение отдельного стенда — стандартное правило для всех проектов по нагрузочному тестированию. Если параллельно с нагрузкой на нем проводят другие работы, то они могут исказить результаты проведенных тестов.
Но в жизни не всегда получается следовать правилам.
На одном из проектов мы изначально работали на отдельном стенде, который был выделен под наши работы на определенный срок. Все было хорошо, но в процессе разработка стала пробуксовывать по срокам, из-за чего, в свою очередь, сдвинулись сроки работ по нагрузочному тестированию. В итоге в какой-то момент на одном стенде оказались и мы, и разработка, и приемочное тестирование.
Ошибки при таком соседстве на стенде неминуемы. При параллельной работе на стенде будет очень сложно разобрать по графикам, на что повлиял запуск нагрузочного тестирования, а какие скачки ресурсов связаны с посторонними работами.
Нагрузку в этом случае переносят на ночь или выходные. Это тоже не лучшее решение проблемы, потому что переработки и сверхурочная работа выматывают команду и приводят к непредвиденным издержкам. За тестами же надо следить, чтобы избежать неприятных сюрпризов, таких как аварийное падение теста или стенда под высокой нагрузкой, из-за чего придется переделывать всю работу.
В моей практике был случай, когда при отладке теста на проведение деклараций по НДС по нескольким юрлицам одновременно с фоновой нагрузкой мы столкнулись с блокировкой PostgreSQL, которая привела к полной остановке работ на стенде на один час. Не только наших, всех работ, что были на стенде.
Чтобы избежать подобных ситуаций, стоит всегда с самого начала планировать выделение отдельного стенда в монопольное пользование командой нагрузки, равного продуктивному по мощности. Иначе может сложиться ситуация, что сроки предоставления стенда вышли и он теперь запланирован под другие работы.
Если выделить отдельный стенд не получается, то при планировании сроков проекта заложите риски, что работы на каждом из этапов могут продлиться дольше. Иначе любая задержка на критическом пути проекта приведет к задержке проведения нагрузочного тестирования.
Ошибка № 2. Редко привлекать функционального архитектора
В случае с 1С в состав стандартной команды нагрузочного тестирования будет совсем не лишним привлекать эксперта по этой системе.
Архитектор знает, где что может «болеть» у 1С, и дает очень ценные советы, позволяющие быстрее находить дефекты, не тратить время на лишние проверки, а бить прямо в цель.
Например, на одном из проектов нам необходимо было проверить проведение амортизации параллельно по пяти организациям с 500 тысячами основных средств на каждой. Мы потратили бы много времени на наполнение базы достаточным количеством данных. Но функциональный архитектор сразу указал, что проблемным местом скорее всего станет 100 тысяч основных средств.
Дело в том, что платформа 8.3 имеет определенную специфику: при записи больших массивов данных в регистры, содержащие свыше 100 тысяч строк, а для балансового регистра бухгалтерии с поддержкой корреспонденции и того меньше — 50 тысяч, платформа ставит управляемую блокировку на весь регистр. Из-за этого все другие операции амортизации, выполняемые параллельно в этот момент, завершаются с ошибкой из-за конфликта блокировок. Мы могли потратить много времени на бесполезное наполнение базы данных целевым объемом данных, а в итоге сделали все гораздо раньше, потому что проконсультировались с функциональным архитектором.
Из этой истории, кстати, вытекает следующая ошибка.
Ошибка № 3. Тестировать сразу на полном объеме данных
Совсем не обязательно проводить нагрузочное тестирование на полном объеме имеющихся или планируемых данных. Зачастую уже при тестировании на небольшом количестве видно, потребуется доработка функционала или нет.
Например, мы тестировали перепроведение документов. Заказчик просил проверить эту операцию на 5 миллионах документов. Наполнение базы таким количеством данных и само тестирование заняли бы очень много времени.
Мы проверили процесс на нескольких десятках тысяч документов. И уже на этом объеме данных получили искомый результат: скорость проведения операции неудовлетворительная, необходима доработка.
Ошибка № 4. Использовать одну тестовую базу данных и редко делать бэкапы
В ходе нагрузочного тестирования редко проверяют один процесс, чаще всего несколько. А вот базу данных для тестов порой используют одну и ту же. Это может приводить к временным простоям, и вот почему.
При тестировании производительности часто проверяют, как определенные операции будут работать не на фактическом объеме данных, а том, который прогнозируется через 1-2 года. Если ожидается рост организации, а значит, и количества сотрудников, операций, проектов, то данных для теста нужно очень и очень много.
Наполнение базы данных выполняется скриптами, которые пишут сами тестировщики или выделенные на проект разработчики. Скрипты запускаются и начинают генерировать нужное нам количество данных. Это небыстрый процесс, он может занять не часы, а дни или даже недели.
А теперь представим, что разработчик не предусмотрел заполнение какого-то одного параметра в наполняемых данных. Из-за этого дальнейшее тестирование может выдавать ошибку. Для ее исправления все данные надо пересмотреть еще одной обработкой и заполнить отсутствующий параметр. На это нужно будет время. Если исправление не поможет и все сгенерированные данные не подойдут для тестирования, удаление тоже займет некоторое время. В такие моменты восстановление базы данных из бэкапа позволит откатиться на версию до наполнения и продолжить работу без проблемных данных.
Обновление конфигурации на системе с большим количеством данных — это тоже то еще удовольствие. Чем больше раздута база, тем дольше будет процесс.
На одном проекте у нас было пожелание от заказчика — использовать очень большое количество данных, на которых надо протестировать разные процессы. В какой-то момент наша база так разрослась данными, что установка обновлений длилась два дня, а порой и падала в ошибку, не завершившись.
На будущее я взяла за правило в таких случаях заводить разные базы данных, каждую наполнять определенным типом данных и всегда иметь под рукой исходный бэкап с настроенной базой, но без кучи нагенеренного для нагрузочного тестирования.
Ошибка № 5. Не определять SLA перед проведением тестирования
Мой опыт показывает, что перед стартом проекта обязательно надо фиксировать целевые показатели времени или скорости выполнения операций.
Часто нам просто озвучивают пожелание к запуску «Замерить, сколько будет длиться процесс на определенном количестве данных» без каких-либо ограничений по длительности. Но никогда нельзя предсказать с полной уверенностью, сколько времени займет нагрузочное тестирование. Пусть даже очень размытые, но должны быть какие-то ориентиры.
Однажды у нас был случай, когда заказчик попросил проверить, сколько будет длиться процесс закрытия месяца при наполнении базы количеством данных, которое прогнозируется в компании через два года. Запустили тест, и он продолжался без остановки несколько дней. Прошла неделя, вторая, и он не прекращался. Вряд ли бы это устроило заказчика, поэтому мы принудительно остановили тест на 17-й день его выполнения.
Теперь я заранее убеждаю заказчика, что необходимы хотя бы ориентировочные сроки работы процесса в заданной конфигурации, которые считаются допустимыми, чтобы не тратить время зря.
Вот таким получился мой личный топ ошибок на проектах по нагрузочному тестированию 1С. Добавляйте в комментариях свои или чужие ошибки, с которыми вы сталкивались. Пусть они помогут другим избежать подобных факапов.