Новости экономики 
Рынок российского ПО переживает тектонические сдвиги. Если еще пару лет назад слово «импортозамещение» вызывало споры, то сегодня это жесткая реальность. Доля решений на базе 1С в корпоративном секторе стремительно растет, по прогнозам достигая 75% рынка ERP. Компании массами переходят с SAP, Oracle и других зарубежных систем.
Но здесь кроется парадокс. Привыкнув к тяжелой артиллерии западных вендоров с их отлаженными, но дорогими механизмами, бизнес сталкивается с новой реальностью: 1С не "коробка". Это пластилин. Его можно и нужно лепить под себя. Именно в этом месте, где начинается кастомизация и доработка, в дело вступает риск. Ошибки, заложенные на этапе разработки или настройки, могут похоронить любой проект.
Как перейти на 1С без потери производительности и нервов? Ответ - профессиональное тестирование. И здесь у IBS есть чем поделиться, особенно учитывая их опыт в нагрузочных испытаниях для таких гигантов как VK.
Специфика тестирования 1С: Русский код и интеграции
Многие менеджеры ошибочно полагают, что ibs-qa.ru/services/testirovanie_1C/ это то же самое, что проверка любой другой информационной системы. Это заблуждение. Платформа имеет уникальный технологический стек, который диктует свои правила игры.
Во-первых, русскоязычный код. Да, запросы к базам данных пишутся на великом и могучем. Это парадоксальным образом облегчает вход в профессию для новых тестировщиков, но усложняет автоматизацию стандартными западными инструментами (Selenium, JMeter "из коробки" тут часто бессилен). Во-вторых, многообразие конфигураций. Тестировщик обязан не просто кликать мышкой, а глубоко понимать бизнес-логику конкретного решения: будь то «1С:ЗУП», «ERP» или «Управление холдингом».
Самая же частая боль интеграции. Редко какой проект живет в вакууме. 1С обменивается данными с банками, торговыми площадками, сайтами на Bitrix24 и десятками других систем. Следовательно, тестировать нужно не одну базу, а целый контур. Причем поток данных идет в обе стороны: выгрузка и загрузка. Ошибка в формате обмена может привести к тому, что бухгалтерия уйдет на выходные, а зарплата сотрудникам зависнет в неизвестности. Команда IBS, например, при внедрении 1С для VK отлаживала более 85 интеграционных потоков.
Автоматизация против ручного труда: Война или союз?
Здесь часто возникает философский спор: что лучше, ручное или автоматизированное тестирование? Ответ - комбинация.
Ручной режим незаменим, когда речь идет об исследовательском тестировании и проверке юзабилити. Человек видит картину целиком. Он может оценить, насколько красиво (или уродливо) расположены кнопки, и понять, что система "думает" слишком долго, хотя формально операция завершилась успехом. Это классика. Без ручного прогона ключевых бизнес-сценариев не обходится ни один релиз.
Автоматизация про скорость и регресс. Когда разработчики правят код, очень легко сломать то, что работало годами. Автотесты (например, на базе Vanessa Automation или собственных разработок IBS - Qual IT) запускаются на ночь, гоняют тысячи сценариев, а утром выдают отчет: "Вот здесь все сломалось". Это экономит часы ручной работы. Однако автоматизация требует вложений на старте. Писать сценарии - дорого. Поэтому разумно автоматизировать только то, что стабильно и будет жить долго.
Нагрузочное тестирование: Где ломаются ERP-гиганты
Это самая острая тема для крупного бизнеса. Руководитель может простить мелкий баг в форме, но никогда не простит, если система "ляжет" при закрытии месяца или в час пик, когда менеджеры выставляют счета.
Нагрузочное тестирование 1С высший пилотаж. Здесь нельзя действовать "на глаз". Команда IBS на своем опыте выделила несколько типовых граблей, в которые наступают все:
- Проблема блокировок. Платформа 1С 8.3 имеет неприятную особенность: при попытке записи больших массивов данных в регистр (например, при амортизации ОС) происходит блокировка. Как только число строк переваливает за 100 тысяч, система встает намертво. Ручное тестирование этого никогда не покажет, так как тестировщик вводит 5-10 документов. Нужен прогон на реальных объемах.
- Утечки памяти и "тяжелые" запросы. Часто проблема не в коде 1С, а в неправильно настроенном сервере баз данных (PostgreSQL или MS SQL). Нагрузочные тесты (с использованием Apache JMeter или "1С:Тест-центра") позволяют снять показатели утилизации CPU и RAM. Если на тестовом стенде нагрузка далека от реальной, вы купите серверов на миллион рублей больше, чем нужно, либо наоборот - сэкономите и получите коллапс.
Интересный кейс от IBS: при проверке формирования счетов-фактур на авансы (100 тысяч авансов) исходный процесс занимал больше 48 часов. Это нонсенс. После оптимизации и внедрения многопоточной обработки удалось сократить время в 10 раз. Но чтобы принять решение о рефакторинге, нужно сначала цифрами доказать, что "так жить нельзя". Это и дает нагрузочное тестирование.
Пять фатальных ошибок при подготовке к тестам
Опираясь на реальные факапы с проектов, можно составить список того, что убивает качество проверки:
- Экономия на стенде. Нельзя проводить нагрузочное тестирование на том же сервере, где сидят разработчики и выкладывают свежие релизы. Пока тестировщик гоняет 5000 пользователей, программист запускает тяжелую сборку - результаты теста превращаются в мусор. Нужен отдельный полигон, максимально похожий на "продуктив".
- Тестирование на "чистом" листе. База в 10 мегабайт летает всегда. А реальная база клиента - 250 ГБ и 3 года истории. Тестировать функционал нужно на объемах данных, приближенных к боевым. Иначе вы просто не увидите тормозов.
- Игнорирование архитектора. Тестировщик видит симптом (система тормозит), но не всегда знает анатомию. Функциональный архитектор 1С сразу скажет: "Не проверяй тут 5 миллионов строк, проблема вылезет уже на 50 тысячах из-за блокировки регистра". Это экономит недели работы.
- Отсутствие бэкапов. Нагенерять тестовых данных труд на несколько дней. А потом скрипт упал и все сломал. Без свежего бэкапа вы потеряете кучу времени на восстановление. Правило хорошего тона - иметь чистый "слепок" базы перед каждым серьезным забегом.
- Размытые критерии приемки (SLA). Если заказчик говорит "просто замерьте скорость" ловушка. Что значит "быстро"? 10 секунд или 10 минут? Без четко прописанных цифр (например, "открытие формы документа не более 3 секунд при 100 одновременных пользователях") проект рискует уйти в бесконечную доработку и споры.
Сравнительная таблица подходов к тестированию 1С
Для наглядного понимания различий между методами проверки приведем сравнительную характеристику основных подходов, используемых профессиональными командами.
| Критерий сравнения | Ручное тестирование | Автоматизированное тестирование | Нагрузочное тестирование |
|---|---|---|---|
| Затраты на старте | Низкие (нужен только тестировщик) | Высокие (написание скриптов) | Средние (настройка стенда и ПО) |
| Скорость прогона | Низкая (зависит от человека) | Очень высокая (ночные прогоны) | Средняя (длительные сценарии) |
| Выявление визуальных багов | Да (человек видит интерфейс) | Ограниченно (только по скриншотам) | Нет (цель - производительность) |
| Проверка блокировок в БД | Нет (невозможно воспроизвести) | Частично (только с эмуляцией) | Да (основная задача) |
| Идеальный сценарий применения | Новый функционал, юзабилити | Регресс, стабильные модули | Закрытие месяца, пиковые нагрузки |
Как IBS строит процессы контроля качества
Профессиональный подход к тестированию 1С подразумевает не просто "поиск багов", а системную инженерию качества. В IBS этот процесс завязан на три кита: независимость, инструментарий и экспертиза.
Независимость означает, что тестировщики отдельная команда, не подчиненная разработчикам. Это исключает ситуацию "свои же не видят ошибок своих детей". Когда релиз готовится к выходу, именно независимые QA-инженеры дают "добро" или "отбой".
Что касается инструментов, то здесь используется связка из открытых решений (Vanessa ADD, Selenium) и тяжелого проприетарного артиллерийского оружия вроде Load IT (собственная разработка IBS) для управления нагрузкой. Это позволяет не только найти баг, но и дать разработчику точную ссылку на проблемную строку кода и стек вызовов.
Экспертиза складывается из кейсов. Опыт, полученный на проектах VK, крупных бетонных заводах и холдингах, позволяет прогнозировать риски. Например, знание о том, что PostgreSQL может встать на час из-за блокировки при заполнении книг НДС, позволяет закладывать в архитектуру решение "из коробки" - например, выделение временного окна для регламентных операций.
Реальный кейс из практики: на одном из внедрений ERP-системы в строительном холдинге команда IBS обнаружила, что формирование регламентированной отчетности занимало 14 часов. После серии нагрузочных тестов и оптимизации запросов время сократилось до 25 минут. Экономия рабочего времени бухгалтерии составила более 300 человеко-часов ежемесячно.
Тестирование 1С сегодня не прихоть, а бизнес-необходимость. В условиях, когда цена ошибки - остановка производства или невыплата зарплаты, пренебрегать качеством просто глупо. При переходе на отечественное ПО не надейтесь на "авось". Требуйте от подрядчика не только кодеров, но и профессиональных тестировщиков с опытом нагрузочных испытаний.
Компании вроде IBS проходят этот путь десятки раз. Их методики позволяют не просто найти узкие места, но и оптимизировать инфраструктуру, иногда высвобождая до 30% неиспользуемых мощностей "железа". И помните: самый дешевый баг тот, который нашли на тестовом стенде, а не в глазах гендиректора во время сдачи проекта.