Как встроить сценарное тестирование 1С в CI/CD: пошаговая схема

Чтобы встроить сценарное тестирование 1С в CI/CD, подготовьте изолированную тестовую информационную базу, сохраните сценарии и связанные материалы в контролируемой структуре, настройте запуск через 1С:Тестировщик на CI-runner и публикуйте отчет после каждого прогона. Workflow может запускаться при push, pull request или по расписанию. Критическая ошибка должна менять статус job и блокировать дальнейшее слияние или выпуск сборки.

Рабочая цепочка выглядит так: commit в репозитории → запуск workflow → получение версии конфигурации → подготовка тестовой базы → запуск сценариев 1С:Сценарного тестирования через 1С:Тестировщик → сбор логов и отчета → решение по изменению. Команды запуска, поддерживаемые режимы и формат артефактов зависят от версии платформы 1С и конкретного релиза инструментов. Перед настройкой CI сверяйте параметры с документацией этой версии.

Такой контур сокращает ручную регрессию, раньше выявляет ошибки в критичных процессах и дает команде единый критерий приемки. Сценарии не покрывают весь код и не заменяют нагрузочные, интеграционные и исследовательские проверки. Польза появляется там, где команда выбирает повторяемые пользовательские потоки, готовит предсказуемые данные и разбирает каждый failed-прогон.

Как работает сценарное тестирование 1С в контуре CI/CD

Что автоматизирует 1С:Сценарное тестирование

Сценарное тестирование проверяет действия пользователя в прикладном решении 1С. В сценарий можно включить открытие раздела, вход под определенной ролью, заполнение реквизитов, создание документа, проведение операции, формирование отчета и проверку результата. Последовательность должна описывать бизнес-процесс, а не набор случайных кликов.

Пример пользовательского потока для конфигурации, где есть нужные объекты: пользователь открывает форму заказа, выбирает контрагента и номенклатуру, указывает количество, записывает документ, проводит его, после чего проверяется статус документа, движение по регистрам и итог в отчете. Названия документов, регистров и реквизитов зависят от конфигурации.

Сценарные проверки нужно отличать от других видов тестов:

• Сценарный тест проходит через пользовательскую последовательность и оценивает результат операции.
• Функциональный тест проверяет отдельную функцию или набор правил, иногда без полного пользовательского маршрута.
• Тест на уровне кода анализирует процедуры, функции, запросы и внутреннюю логику.
• Нагрузочная проверка оценивает поведение системы при заданном количестве пользователей, операций или объеме данных.

1С:Сценарное тестирование и 1С:Тестировщик подходят для автоматизации заранее описанных пользовательских потоков. Они не дают автоматического покрытия всех ветвей прикладного кода и не обнаруживают ошибки, для которых в сценарии нет проверяемого результата.

Путь изменения от commit до результата теста

1. Разработчик фиксирует изменение конфигурации в репозитории и создает commit.
2. CI-платформа получает событие push или pull request и запускает workflow.
3. Runner получает нужную версию исходников и подготавливает компоненты 1С.
4. Система создает тестовую базу или восстанавливает ее из подготовленной копии.
5. 1С:Тестировщик запускает выбранный набор сценариев.
6. CI сохраняет статус, логи, отчет и сведения об окружении.
7. Правило pipeline разрешает слияние или блокирует его по результату проверки.

Для небольшого pull request можно запускать короткий smoke-набор. После слияния подходит расширенный функциональный прогон. Полную регрессию удобно запускать ночью, после крупных изменений и перед релизной сборкой. Такой график снижает время обратной связи, сохраняя контроль над критичными процессами.

Какие задачи решает автоматизация сценарного тестирования 1С

• Сокращает количество повторяющихся ручных проверок перед выпуском.
• Проверяет критичные операции после изменения форм, ролей, реквизитов и алгоритмов.
• Фиксирует единый порядок действий для разных тестировщиков.
• Помогает находить регрессии сразу после push или pull request.
• Связывает результат теста с конкретным commit и версией конфигурации.
• Дает измеримый статус для решения о слиянии и выпуске.

Автоматизация не устраняет ручное тестирование. Человек по-прежнему нужен для проверки новых требований, сложных пользовательских решений, удобства интерфейса, нестандартных данных и причин, которые сценарий не умеет распознать.

Что проверить до настройки: версии, роли и тестовый контур

До подключения CI зафиксируйте состав окружения. Ошибка в версии платформы или способе запуска часто выглядит как дефект теста, хотя сценарий не успевает начаться. Чек-лист подготовки можно оформить в отдельной задаче и закрывать по каждому стенду.

Совместимость платформы, конфигурации и инструмента

Не копируйте команду из инструкции для другой версии без проверки. Сначала выполните локальный запуск на чистой тестовой базе, затем повторите его на том же runner, который использует CI.

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

Изолированная тестовая информационная база

Тесты нельзя запускать на рабочей базе. Сценарий может провести документ, изменить остатки, создать пользователей, отправить запрос во внешнюю систему или удалить подготовленные данные. Для CI нужна копия или специально собранная база без доступа к продуктивным данным.

Тестовый контур должен иметь четыре свойства:

• Предсказуемость: начальные данные известны и подходят выбранным сценариям.
• Восстанавливаемость: после прогона базу можно вернуть в исходное состояние.
• Изолированность: операции тестов не меняют продуктивные документы и справочники.
• Наблюдаемость: команда получает логи, статус и сведения о версии окружения.

Для параллельных job подготовьте отдельную базу на каждый поток или заранее разделите наборы так, чтобы они не изменяли общие записи. Одна база с одинаковыми объектами для четырех одновременных прогонов часто дает блокировки, зависимость от порядка и ложные падения.

Учетные записи, права и доступ агента CI

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

Проверьте четыре группы доступа:

• доступ runner к серверу 1С, СУБД и тестовой информационной базе;
• доступ CI к репозиторию и нужной ветке;
• доступ к хранилищу отчетов и артефактов;
• доступ к секретам, где хранятся пароли, токены и строки подключения.

Пароли и токены не записывайте в workflow и файлы сценариев. Используйте хранилище секретов CI, ограничивайте срок действия ключей и меняйте их после смены владельца стенда. В отчете не должны появляться пароли, токены и реальные персональные данные.

Какие навыки нужны команде на старте

Для первого пилота команде нужны базовые навыки в пяти областях:

1. Работа с конфигурацией 1С, формами, ролями, документами и регистрами.
2. Создание и отладка сценариев в 1С:Сценарном тестировании.
3. Подготовка тестовых данных и восстановление информационной базы.
4. Git, ветвление и чтение YAML-workflow или аналогичной CI-конфигурации.
5. Диагностика логов, статусов job и проблем тестового сервера.

Разработчик 1С отвечает за совместимость изменения со сценариями, тестировщик формирует проверки и анализирует результат, DevOps-инженер настраивает runner и pipeline. В небольшой команде эти роли может совмещать один человек, но зоны ответственности нужно зафиксировать заранее.

Как спроектировать сценарии для 1С:Сценарного тестирования

Выбор процессов для первого набора тестов

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

Приоритет удобно оценивать по трем показателям:

• частота ручной проверки;
• частота дефектов после изменений;
• стоимость ошибки для бизнеса.

Для пилота достаточно выбрать 3-5 стабильных сценариев. Например, для учетной конфигурации это может быть ввод первичного документа, проведение операции, проверка движения по регистру и формирование итогового отчета. Для аудиторского решения подойдут расчет риска, определение существенности и подготовка рабочей документации. Практический обзор этих задач собран в статье об автоматизации аудиторских проверок в 1С.

Структура надежного тестового сценария

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

1. Подготовка состояния: восстановить базу или создать нужные записи.
2. Вход пользователя: выбрать учетную запись и проверить доступ к нужному разделу.
3. Последовательность действий: заполнить формы, записать и провести документы.
4. Промежуточные проверки: проверить реквизиты, статусы и доступность следующего шага.
5. Итоговая проверка: сравнить данные, движения, отчет или сообщение системы с ожидаемым результатом.
6. Очистка: удалить созданные объекты или восстановить исходную копию базы.

Не скрывайте предусловия в ручных действиях. Формулировка «в базе уже есть нужный контрагент» недостаточна, если сценарий не создает его и не получает его из фиксированного набора данных. Зафиксируйте идентификатор, реквизиты и состояние объекта.

Проверки результата вместо проверки самого факта клика

Сценарий, который проверяет только открытие формы и нажатие кнопки, может завершиться успешно при неверном расчете. В каждой критичной последовательности нужен измеримый результат.

• Документ записан и получил ожидаемый статус.
• Проведение создало нужные движения по регистрам.
• Сумма, ставка, количество или остаток совпали с ожидаемым значением.
• Отчет сформирован и содержит нужные строки или итоги.
• Пользователь с ограниченной ролью видит разрешенную операцию.
• Пользователь без нужного права получает отказ.
• Обмен создал или обновил объект с ожидаемым результатом.

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

Именование, группировка и связь сценариев с релизами

Единое имя облегчает поиск в отчете и навигацию по набору. Практичный шаблон: область_процесс_операция_ожидаемый_результат. Пример: Продажи_Заказ_Проведение_ДвиженияСозданы.

Группируйте сценарии по бизнес-процессам и скорости:

• smoke: запуск приложения, авторизация, ключевые формы и одна базовая операция;
• functional: проверки отдельной области конфигурации;
• regression: полный набор повторяемых проверок перед выпуском.

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

Как подготовить эталонные базы, ожидаемые результаты и артефакты

Подготовка исходного состояния тестовой базы

Случайные данные и следы предыдущего прогона искажают результат. Выберите один способ подготовки базы и применяйте его одинаково для локального запуска и CI.

Для первого пилота обычно проще восстановить копию с минимальным набором данных. Время подготовки измеряйте отдельно от времени выполнения сценариев. Если база восстанавливается 12 минут, а сами тесты идут 4 минуты, ускорять интерфейсные шаги преждевременно.

Что считать эталоном проверки

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

• Исходная база задает начальное состояние.
• Ожидаемый результат описывает, что должно измениться после операции.
• Технический отчет фиксирует фактический ход теста, ошибки и окружение.

Эталоном может быть значение реквизита, статус документа, набор движений, сумма отчета, наличие объекта или отказ в доступе. Скриншот формы подходит для визуальной проверки, но зависит от разрешения экрана, версии клиента и текста интерфейса. Файловый эталон требует контроля формата, кодировки и правил сравнения.

Версионирование эталонов и тестовых данных

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

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

• номер задачи или релиза;
• автора изменения;
• старый и новый результат;
• причину замены;
• сценарии, которые повторно проверили.

Если эталон меняют одновременно с кодом без объяснения, регрессия может исчезнуть из отчета. Контрольная история нужна для защиты от такого эффекта.

Какие артефакты сохранять после прогона

CI должен сохранять материалы даже при failed-статусе. Минимальный набор включает:

• отчет о выполнении сценариев;
• логи 1С:Тестировщика и runner;
• идентификатор commit или pull request;
• версию платформы 1С и конфигурации;
• название тестовой базы или ее технический идентификатор;
• параметры запуска без секретов;
• сведения о времени начала, завершения и длительности;
• снимки экрана или файлы, если их формирует выбранная связка инструментов.

В workflow задайте публикацию отчета отдельным шагом, который выполняется после тестов независимо от их результата. Разработчик должен открыть отчет из карточки commit или pull request без повторного запуска на локальном компьютере.

Как встроить 1С:Тестировщик в pipeline CI/CD

Выбор триггеров: push, pull request и расписание

Триггер выбирают по цене ошибки и допустимому времени обратной связи.

Автоматический запуск на сервере убирает зависимость от ручного прогона на компьютере разработчика. Для pull request нужен быстрый и стабильный feedback. Полный регресс не должен замедлять каждое небольшое изменение, если его можно запланировать отдельно.

Из каких шагов состоит workflow

Workflow в CI описывает runner, зависимости, порядок операций и место хранения отчета. Универсальная схема выглядит так:

1. Получить исходники: выполнить checkout нужной ветки или commit.
2. Подготовить runner: проверить платформу, лицензии, компоненты 1С и свободное место.
3. Подключить секреты: передать учетные данные безопасным способом.
4. Подготовить базу: восстановить копию, загрузить данные или создать изолированный экземпляр.
5. Запустить 1С-тесты: передать путь к базе, набору сценариев и каталогу отчета.
6. Собрать результаты: сохранить отчет, логи и сведения об окружении.
7. Очистить ресурсы: удалить временную базу и файлы, которые не нужны после завершения.
8. Вернуть статус: передать CI результат проверки и применить правило блокировки.

В GitHub Actions и аналогичных системах эти шаги описывают в workflow-файле. Конкретная платформа CI может использовать другой синтаксис, но состав операций остается близким.

trigger: push, pull_request, schedule
runner: подготовленный тестовый сервер
steps: checkout, prepare, run-tests, collect-report, cleanup
gate: pass или fail

Этот фрагмент показывает логику pipeline и не служит готовой командой для конкретной версии 1С. Синтаксис запуска 1С:Тестировщика нужно брать из документации используемого релиза.

Запуск тестов из CI: что нужно проверить в команде

До добавления команды в workflow составьте таблицу параметров и заполните ее фактическими значениями тестового стенда.

Сначала проверьте одну команду на runner вручную в служебном режиме. Зафиксируйте фактический код возврата при успешном прогоне, ошибке сценария и недоступной базе. После этого переносите запуск в workflow.

Правило прохождения и блокировка проблемного изменения

Разделите результаты минимум на пять статусов:

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

Ошибка теста должна блокировать merge для критичного набора. Ошибка окружения требует устранения причины и повторного запуска. Нестабильный тест нельзя автоматически считать успешным: его нужно поместить в отдельный список, назначить владельца и ограничить срок исправления.

Публикация отчетов в CI

Отчет храните как артефакт конкретной job. Свяжите его с commit, pull request, веткой и версией конфигурации. В интерфейсе CI разработчик должен видеть как минимум имя первого упавшего сценария, шаг с ошибкой, короткое сообщение и ссылку на полный лог внутри интерфейса pipeline.

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

Как запускать автоматические тесты 1С в разных режимах

Smoke-набор для pull request

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

Для команды можно задать ориентир, например лимит 10 минут на smoke-job. Это не универсальная норма: фактическое время зависит от подготовки базы, способа подключения и числа сценариев. Если набор регулярно превышает лимит, его нужно разбить на обязательную часть и расширенные проверки.

Функциональный и полный регрессионный прогон

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

Записывайте длительность каждой группы. Пример: продажи занимают 8 минут, склад 14 минут, обмены 22 минуты. Такие данные помогают решить, что запускать последовательно, что разделить между job и где причина задержки связана с базой, а не с количеством шагов сценария.

Проверка разных вариантов окружения

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

В матрицу могут попасть:

• две поддерживаемые версии платформы 1С;
• клиентский и серверный режим;
• разные СУБД, если проект их действительно поддерживает;
• разный состав расширений;
• разные наборы исходных данных.

Не создавайте матрицу ради количества job. Каждый вариант должен соответствовать реальному сценарию эксплуатации и иметь ответственного за анализ результата.

Ночные и релизные прогоны

Полный набор удобно запускать по расписанию, после крупных изменений и перед релизной сборкой. Ночной прогон освобождает pull request от долгих проверок, но не заменяет smoke-набор при изменении кода.

Релизный pipeline должен использовать зафиксированную версию конфигурации, чистую тестовую базу и полный набор артефактов. Если ночной прогон завершился ошибкой, утром команда должна видеть commit, первый упавший шаг и готовый отчет, а не только красный индикатор.

Как ускорить прогон: кэширование, шардирование и параллельное выполнение

Когда параллелизация действительно нужна

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

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

Матрица CI-задач и распределение наборов

CI-платформы умеют запускать несколько job через матрицу. В простом варианте одна job проверяет продажи, вторая склад, третья бухгалтерские операции, четвертая обмены. После завершения pipeline собирает общий статус всех частей.

Шардирование делит общий набор тестов на части. Например, четыре shard-job получают четверти набора и выполняются одновременно. Такой подход сокращает календарное время, если базы, runner и сценарии не конфликтуют.

Механизм разделения нужно подтвердить для конкретной версии 1С:Тестировщика. Если встроенного шардирования нет, распределяйте группы сценариев на уровне матрицы CI. Отчет каждой части сохраняйте с уникальным именем, иначе параллельные job могут перезаписать артефакты друг друга.

Конфликты при общей тестовой базе

Параллельные сценарии могут изменять одни документы, блокировать записи, использовать одинаковые номера или зависеть от порядка выполнения. В результате тесты будут падать даже при исправной конфигурации.

Используйте один из вариантов:

• отдельная копия базы для каждой job;
• изолированный набор данных для каждой группы;
• жесткое распределение объектов без пересечения;
• последовательный запуск сценариев, которые зависят от общего состояния.

Проверяйте изоляцию искусственно: запустите два одинаковых набора одновременно и сравните результаты с одиночным прогоном. Если статусы различаются, общая база или порядок выполнения влияют на тест.

Кэширование компонентов CI

Кэширование сокращает подготовительную часть job. В кэш можно помещать редко меняющиеся зависимости и бинарные компоненты, если правила проекта и лицензирование это допускают. Для ключа кэша используйте версию платформы, инструмента, операционной системы и runner.

При обновлении платформы или 1С:Тестировщика меняйте ключ. Иначе runner может получить старый компонент и показать ошибку, не связанную с изменением конфигурации. Механизм вроде actions/cache применяют в CI для повторного использования подготовленных файлов, но конкретные пути и сроки хранения зависят от выбранной платформы.

Как измерять эффект ускорения

Сравнивайте показатели до и после изменения pipeline:

• общее время workflow;
• время восстановления или подготовки базы;
• длительность каждого набора;
• время ожидания runner;
• доля повторных запусков;
• число конфликтов при параллельном выполнении;
• процент занятых ресурсов.

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

Как разбирать падения и поддерживать стабильность тестов

Падение продукта, теста или окружения

Первый шаг при failed-статусе, зафиксировать commit, версию платформы, конфигурацию, имя базы и параметры запуска. Затем откройте отчет и найдите первый упавший шаг. Последующие ошибки могут быть следствием одного сбоя.

Классифицируйте причину:

• Дефект конфигурации: система получила неверный результат при корректных действиях.
• Ошибка сценария: шаг использует устаревшее имя формы, реквизита или неверное предусловие.
• Проблема данных: база не восстановилась или в ней отсутствует нужный объект.
• Сбой инфраструктуры: недоступен сервер, закончилась лицензия, оборвалась сеть или не хватило ресурсов.
• Нестабильность: одинаковый запуск в одинаковом окружении дает разные статусы.

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

Логи и артефакты как основа расследования

Отчет без окружения редко объясняет причину. Связывайте каждый прогон с commit, версией платформы 1С, релизом конфигурации, тестовой базой, runner и параметрами запуска.

Алгоритм расследования состоит из семи действий:

1. Открыть job, которая завершилась с ошибкой.
2. Найти первый failed-сценарий.
3. Определить первый шаг с отклонением результата.
4. Проверить логи инструмента и сервера.
5. Восстановить ту же тестовую базу.
6. Повторить сценарий локально или на выделенном runner.
7. Назначить причину и владельца исправления.

Если ошибка связана с блокировками, длительными запросами или технологическим журналом, полезно систематизировать базовые методы диагностики в плане подготовки по технологическим вопросам 1С. Материал не заменяет расследование конкретного падения, но помогает выбрать направление проверки.

Нестабильные тесты и повторный запуск

Нестабильный, или flaky-тест, дает разные результаты при неизменном коде и одинаковом окружении. Причиной могут быть время, случайные данные, сетевой сервис, фоновые задания, порядок выполнения или общая база.

Введите правило диагностики: повторить один сценарий 10 раз на одной восстановленной базе и записать результаты. Если один и тот же тест хотя бы раз меняет статус без изменения исходников, его нужно пометить как нестабильный и проверить зависимости.

Повторный запуск нужен для подтверждения и расследования. Автоматический retry не должен превращать failed в pass без отдельного статуса. Для flaky-теста назначьте владельца и срок исправления, например 5 рабочих дней. До исправления исключайте его из блокирующего набора только с явной записью причины.

Обновление сценариев после изменения интерфейса

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

Порядок обновления должен быть таким:

1. сопоставить изменение с требованием или задачей;
2. проверить, изменился ли ожидаемый бизнес-результат;
3. обновить шаги и предусловия;
4. повторить сценарий на чистой базе;
5. проверить связанные smoke- и регрессионные наборы;
6. зафиксировать причину изменения сценария.

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

План подключения сценарного тестирования 1С: от пилота до обязательного контроля

Этап 1. Инвентаризация процессов и рисков

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

Приоритизируйте процессы с высокой повторяемостью и заметным риском. Запись «проверить продажи» слишком широкая. Запись «создать заказ, провести отгрузку, проверить остаток и итог отчета» подходит для оценки и последующей автоматизации.

Этап 2. Пилот на ограниченном наборе сценариев

Выберите 3-5 устойчивых процессов и подготовьте одну изолированную базу. Сначала запустите сценарии локально, затем повторите тот же набор на runner. Не меняйте одновременно платформу, конфигурацию, способ подготовки базы и CI-платформу, иначе причина ошибки останется неясной.

Зафиксируйте базовые показатели:

• время подготовки базы;
• время выполнения каждого сценария;
• процент успешных запусков;
• число ошибок продукта;
• число ошибок окружения;
• время анализа failed-прогона.

Этап 3. Подключение обязательных проверок

После стабилизации пилота назначьте smoke-набор обязательным для pull request. Определите, какой failed-статус блокирует merge, кто принимает решение при ошибке окружения и когда запускается повторная проверка.

Расширяйте обязательное покрытие постепенно. Сначала добавьте критичные операции, затем процессы с высокой частотой ручной проверки. Набор, который часто падает по инфраструктурным причинам, не следует подключать как жесткий gate до устранения нестабильности.

Распределение ответственности в команде

Если один специалист выполняет несколько ролей, разделите задачи хотя бы на уровне списка ответственности. Без владельца тестовый контур быстро устаревает после изменения платформы, конфигурации или инфраструктуры.

Критерии успешного подключения

Оценивать результат нужно по показателям, а не по числу созданных сценариев:

• сократилось время ручной регрессии;
• уменьшилось время обратной связи по pull request;
• выросла доля успешных воспроизводимых прогонов;
• больше дефектов находится до релизной сборки;
• сократилось время разбора failed-статусов;
• критичные процессы связаны с актуальными сценариями;
• отчеты доступны по каждому commit;
• эталоны меняются с объяснением и согласованием.

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

Типовые ошибки при подключении сценарного тестирования 1С

Попытка автоматизировать все процессы сразу

Большой набор на старте перегружает команду сценариями, которые сложно поддерживать. Часть проверок быстро устаревает, а частые ложные падения снижают доверие к pipeline.

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

Запуск на общей или непредсказуемой базе

Общая база смешивает результаты разных job и сохраняет следы прошлых прогонов. Один сценарий может изменить данные, от которых зависит другой, поэтому итог перестает быть воспроизводимым.

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

Отсутствие отчетов и связи с изменением

Красный статус без лога не помогает исправить проблему. Разработчик должен видеть первый упавший шаг, commit, версию конфигурации, базу и параметры запуска.

Сохраняйте отчеты после любого результата, включая сбой runner. Публикуйте их как артефакты и связывайте с pull request. Такой порядок сокращает повторные ручные прогоны только для восстановления контекста.

Слепое копирование команд из инструкции для другой версии

Команда, которая работает на одном релизе платформы, может не подойти другой версии 1С:Тестировщика или runner. Несовместимый параметр приводит к ошибке запуска и создает ложное впечатление, что проблема связана со сценарием.

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

Автоматическое обновление эталонов после любого падения

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

Обновляйте эталон после анализа изменения, повторного прогона и согласования с владельцем бизнес-процесса. В истории храните автора, причину, старое значение и новый результат.

Для безопасного старта достаточно выполнить шесть действий: зафиксировать версии, подготовить изолированную базу, выбрать 3-5 критичных сценариев, проверить их локально, запустить через CI и сохранить отчет. После стабилизации smoke-набора подключайте полную регрессию, матрицу окружений и параллельные job.