Администрирование · 12 мин
Как протестировать 1С: практическое руководство
Практическое руководство по тестированию 1С: виды проверок, тестовые базы, сценарное и нагрузочное тестирование, типичные ошибки и контрольные точки.
Тестирование 1С — это проверка того, что конфигурация, доработки и обмены данными работают корректно до того, как изменения попадут в рабочую среду. Ошибка, обнаруженная на тестовой базе, стоит минут на исправление; та же ошибка в рабочей базе может остановить отгрузки, сломать отчётность или повредить данные.
Подход к тестированию зависит от масштаба изменений. Обновление типовой конфигурации требует одного набора проверок, внедрение собственной доработки — другого, а настройка обмена с сайтом или другой системой — третьего. Общий принцип один: любое изменение сначала воспроизводится на копии базы, проверяется по сценариям, и только после успешного результата переносится в рабочую среду.
В статье разобраны основные виды тестирования, порядок подготовки тестовой среды, практические сценарии проверок и типичные ошибки, которые допускают даже опытные специалисты.
Какие виды тестирования применяются в 1С
Функциональное тестирование проверяет, что конкретная операция работает по задумке: документ проводится, проводки формируются правильно, печатная форма выводит нужные данные. Это базовый вид проверки, который выполняется после любой доработки или обновления.
Регрессионное тестирование отвечает на вопрос: не сломалось ли то, что работало раньше. После обновления конфигурации или установки расширения нужно пройти ключевые бизнес-процессы целиком — от создания заказа до закрытия месяца. Именно регрессия чаще всего пропускается из-за нехватки времени и именно она выявляет самые неприятные сюрпризы.
Нагрузочное тестирование проверяет поведение системы под нагрузкой: как быстро проводятся документы при одновременной работе десятков пользователей, нет ли блокировок, выдерживает ли сервер массовую загрузку данных. Для небольших баз этот вид часто опускают, но при росте числа пользователей или объёма данных он становится обязательным.
Отдельно выделяют тестирование обменов: синхронизация между конфигурациями, обмен с сайтом, ЭДО, банк-клиент. Здесь проверяют не только факт передачи данных, но и корректность соответствия объектов, обработку ошибок и поведение при повторной выгрузке.
Как подготовить тестовую среду
Главное правило: тестирование выполняется на копии рабочей базы, а не на самой рабочей базе и не на пустой демонстрационной. Копия содержит реальные данные, реальные настройки и реальные доработки — только так проверка даёт достоверный результат.
Для файловой базы достаточно скопировать файл 1Cv8.1CD в отдельный каталог и подключить его как новую информационную базу. Для клиент-серверного варианта делают резервную копию средствами СУБД (например, через pg_dump для PostgreSQL или backup в MS SQL) и разворачивают её на отдельном сервере или в отдельной базе с другим именем.
После развёртывания копии выполните три обязательных действия. Во-первых, отключите регламентные и фоновые задания — иначе копия начнёт выполнять обмены и рассылки параллельно с рабочей базой. Во-вторых, убедитесь, что в настройках обменов указаны тестовые адреса или обмены отключены. В-третьих, пометьте базу визуально: измените заголовок окна или добавьте префикс в название, чтобы пользователи не перепутали её с рабочей.
- 1Создайте резервную копию рабочей базы и разверните её в отдельном каталоге или на отдельном сервере
- 2Отключите регламентные и фоновые задания в копии
- 3Отключите или перенастройте исходящие обмены: ЭДО, сайт, банк, синхронизацию с другими базами
- 4Измените заголовок базы, чтобы визуально отличать её от рабочей
- 5Проверьте, что копия открывается и ключевые документы отображаются корректно
Как составить тестовые сценарии
Проверка «на глаз» почти всегда что-то пропускает. Поэтому перед тестированием составьте список сценариев — конкретных последовательностей действий с ожидаемым результатом. Хороший сценарий звучит так: «Создать реализацию от обычного покупателя, провести, проверить проводки по счетам 62 и 90, сформировать УПД, проверить заполнение полей».
Сценарии должны покрывать три группы. Первая — типовые операции, которые выполняются ежедневно: продажа, оплата, поступление, перемещение, начисление зарплаты. Вторая — редкие, но критичные операции: возвраты, корректировки, сторнирование, закрытие периода. Третья — операции, затронутые конкретным изменением: если обновлялся модуль обмена, проверяются все связанные сценарии.
Для каждого сценария фиксируйте результат: пройден, не пройден, пройден с замечаниями. Это позволит вернуться к проблемным местам и доказать, что проверка действительно выполнялась, а не проводилась формально.
Тестирование обновлений конфигурации
Обновление типовой конфигурации — самая частая причина тестирования. Порядок действий стандартный: развернуть копию, выполнить обновление на копии, проверить ключевые сценарии, и только потом повторить обновление на рабочей базе в нерабочее время.
Особое внимание уделите доработкам. Если конфигурация изменена (добавлены реквизиты, изменены модули, подключены расширения), при обновлении возможны конфликты. Проверьте, что все доработки сохранились и работают: откройте изменённые документы, выполните изменённые отчёты, пройдите процессы, которые затрагивали доработки.
После обновления на тестовой копии проверьте также отчётность: сформируйте регламентированные отчёты за последний закрытый период и сравните ключевые показатели с теми, что были сданы. Расхождения — сигнал о проблемах в обновлении или в данных.
Как проверить результат обновления
Соответствует целевому релизу
Версия не изменилась или обновление завершилось с ошибками
Документ проводится, проводки корректны
Ошибки при проведении, пустые или неверные проводки
Показатели совпадают со сданной отчётностью
Суммы расходятся без объяснимой причины
Все изменённые объекты работают как раньше
Доработка исчезла или выдаёт ошибку
Инструменты автоматизации тестирования
Ручное тестирование надёжно, но медленно и плохо масштабируется. Для регулярных проверок существуют инструменты автоматизации. Наиболее известный — Vanessa Automation: открытый инструмент, позволяющий описывать сценарии на языке Gherkin и воспроизводить их автоматически, с записью видео и отчётов об ошибках.
Для тестирования кода разработчики используют фреймворки модульного тестирования (например, xUnitFor1C), которые проверяют отдельные функции и процедуры без участия пользователя. Это удобно для сложных расчётов: алгоритм проверяется на наборе эталонных данных автоматически.
Для нагрузочного тестирования применяется Тест-центр из комплекта инструментов 1С:КИП или специализированные решения. Они эмулируют одновременную работу множества пользователей и показывают, где возникают блокировки и узкие места. Такие проверки имеет смысл проводить перед резким ростом числа пользователей или объёма данных.
Сравнение подходов к тестированию
Подходит для небольших внедрений и разовых обновлений. Ограничение — трудоёмкость и зависимость от внимательности исполнителя.
Подходит для регулярных регрессионных проверок и больших конфигураций. Ограничение — требует первоначальных вложений в разработку и поддержку сценариев.
Подходит для проверки сложных алгоритмов расчёта. Ограничение — проверяет только код, а не поведение системы в целом.
Подходит перед масштабированием системы. Ограничение — требует отдельного стенда и навыков интерпретации результатов.
Типичные ошибки при тестировании 1С
Самая опасная ошибка — тестирование на пустой или демонстрационной базе. На чистых данных всё работает идеально, а проблемы всплывают только на реальных объёмах и реальных частных случаях: старых документах, нестандартных контрагентах, ручных операциях прошлых лет.
Вторая распространённая ошибка — проверка только «счастливого пути», когда тестировщик выполняет операции строго по инструкции. Реальные пользователи нажимают не те кнопки, закрывают окна посередине операции и вводят данные в неожиданном порядке. Хорошая проверка включает хотя бы несколько отклонений от стандартного сценария.
Третья ошибка — забыть про права доступа. Под полными правами всё работает, а у менеджера с ограниченной ролью документ не открывается или отчёт показывает пустой результат. Ключевые сценарии нужно пройти минимум под двумя ролями: администратора и типового пользователя.
Как зафиксировать результат и принять решение о переносе
Тестирование считается завершённым, когда все критичные сценарии пройдены, а найденные ошибки либо исправлены, либо осознанно приняты с оценкой риска. Решение о переносе изменений в рабочую базу принимается на основании зафиксированных результатов, а не ощущения «вроде работает».
Перед переносом в рабочую среду сделайте свежую резервную копию рабочей базы — это обязательное условие отката. Перенос выполняйте в период минимальной активности пользователей, предупредив их заранее. После переноса пройдите два-три самых критичных сценария уже в рабочей базе: это займёт десять минут, но подтвердит, что перенос прошёл корректно.
Как выбрать действие
Если после переноса в рабочую базу обнаружилась серьёзная проблема, не пытайтесь исправлять её «на горячую» — восстановите резервную копию и вернитесь к анализу на тестовой среде. Потеря нескольких часов работы пользователей менее болезненна, чем повреждение учётных данных.
Что важно запомнить
Тестируйте только на копии рабочей базы с отключёнными обменами и регламентными заданиями. Проверяйте по письменным сценариям, включая регрессию, права доступа и граничные случаи. Переносите изменения в рабочую среду только после свежей резервной копии и в нерабочее время.
Частые вопросы о тестировании 1С
Можно ли тестировать обновление сразу на рабочей базе, если база небольшая?
Технически можно, но риск не оправдан даже для маленькой базы. Обновление может завершиться ошибкой посередине процесса, и база окажется в нерабочем состоянии. Развёртывание копии файловой базы занимает несколько минут — это минимальная страховка.
Сколько времени должно занимать тестирование типового обновления?
Для типовой конфигурации без доработок обычно достаточно прохождения 10–20 ключевых сценариев. На практике это от пары часов до одного рабочего дня в зависимости от числа используемых подсистем. Сильно доработанные конфигурации требуют больше времени.
Нужно ли тестировать обмены с сайтом и ЭДО на копии?
Да, но с обязательным условием: обмены должны быть перенаправлены на тестовые контуры внешних систем или полностью отключены. Если копия подключена к рабочему обмену, тестовые документы уйдут контрагентам как настоящие.
Что делать, если на тестовой базе всё работает, а в рабочей появилась ошибка?
Чаще всего причина в различии данных или настроек: в рабочей базе есть документы, которых не было на момент снятия копии, или отличаются настройки прав. Зафиксируйте условия воспроизведения ошибки, при необходимости восстановите резервную копию и повторите проверку на свежей копии с учётом найденного случая.
Кому поручить тестирование — программисту или пользователю?
Оптимально разделить: техническую корректность (проведение, проводки, отсутствие ошибок) проверяет специалист по 1С, а соответствие бизнес-процессу — ключевой пользователь, который понимает, как операция должна выглядеть в реальной работе. Проверка только программистом пропускает прикладные несоответствия.
Стоит ли внедрять автотесты в небольшой компании?
Полноценная автоматизация оправдана при частых обновлениях и большом числе доработок. Для небольшой компании с редкими изменениями достаточно письменного чек-листа сценариев и дисциплины его прохождения. Начать можно с простого документа со списком проверок и результатов.