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

Привет, Хабр! Меня зовут Кравченко Данил, я разработчик 1С в IBS. И в этой статье я решил сделать упор не на технику (про это много кто пишет), а на организационную сторону вопроса. Расскажу, как все выглядит изнутри, с чем реально сталкиваешься на выезде, какие навыки важны, к чему стоит морально готовиться и что может пойти не по плану. Все — на личном опыте нагрузочного тестирования 1С. А в конце — немного полезных советов в стиле «хозяйке на заметку».

Нагрузочное тестирование: soft skills

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

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

Планирование времени в таких проектах — зона ответственности эксперта. Именно он видит всю картину, выставляет приоритеты, формирует задачи и контролирует ход. Я в работе опирался на этот план: эксперт координировал мои задачи, задавал темп, а при необходимости — оперативно вносил правки. Слаженность и ваша умение работать в команде здесь решает все.

И, наконец, последнее качество — методичность и умение работать с результатами. Важно аккуратно собрать ручные замеры, выгрузить информацию из тест‑центра, а также собрать логи технологического журнала и производительности серверов (Performance Monitor для Windows или atop для Linux — как самые простые примеры). Это позволит эксперту быстро подготовить отчет, а команде — оперативно начать работать с результатами.

Нагрузочное тестирование: hard skills

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

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

Второе — умение снимать серверные логи. Мы, например, делали это через PuTTY. Нужно знать консольные команды для Windows или Linux, чтобы получить нужные лог‑файлы и передать их тому, кто будет готовить отчет.

Подготовительный этап: откуда вообще берутся тестовые сценарии?

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

Сначала заказчик определяет критически важные для себя операции, которые нужно нагрузить: контроль длительности выполнения, проверка на блокировки, анализ ресурсоемкости. Кому‑то важно узнать, как быстро проводится закрытие месяца, а кому‑то — не «падает» ли система при массовом вводе документов. Далее этот список согласуется с нашей стороной. И только после финального утверждения начинается следующий этап — написание роботов.

Подготовка и командировка: что важно знать?

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

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

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

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

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

С какими трудностями придется столкнуться

Главное, что нужно понять: ни одно нагрузочное тестирование не проходит за один день. Особенно в мире 1С. И к этому стоит морально подготовиться.

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

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

Проблема с данными — классика жанра. Часто в базах нет нужных данных, и приходится их генерировать: от карточек товаров до тысяч основных средств.

И, конечно, баги в собственных роботах. Причем не просто баги, а такие, где все выглядит нормально, но тест валится. А причина — какая‑нибудь мелочь: неправильное имя реквизита, забытый переключатель, недостающий флаг. И самое неприятное — потратить полдня, чтобы эту мелочь найти.

Вот поэтому к нагрузочному тестированию стоит подходить с готовностью к хаосу. Мелкая ошибка может сорвать все. А времени на переделку часто нет.

Как провести нагрузку без лишнего стресса: личный опыт

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

Второе — не начинайте с полномасштабных тестов. Сначала уменьшите количество виртуальных рабочих мест, ограничьте количество итераций. Проверьте стабильность, и только потом наращивайте нагрузку.

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

Важно держать планку и регулярно сверяться с клиентом. Это экономит нервы и снижает вероятность сюрпризов.

И не забывайте: вы — лицо своей команды. «Держать лицо» — значит быть спокойным, честным и открытым. Если что‑то пошло не так — лучше сообщить сразу. Это вызывает уважение и укрепляет доверие. А доверие — ключ к успешному завершению проекта.