В августе мы провели вебинар «От задачи до работающего автотеста: как создавать и проверять сценарии 1С с помощью AI» с Александром Кунташовым – ведущим разработчиком ИТ-лаборатории Инфостарта и автором курса «Автоматизированное тестирование в 1С».
На вебинаре Александр показал, как с помощью ИИ и Vanessa Automation пройти путь от исходной инструкции до работающего автотеста: подготовить тест-план, исследовать интерфейс, создать сценарий, запустить его и разобрать возникшие ошибки. Почти за три с половиной часа участники получили много практического материала. Если вы пропустили эфир, его можно посмотреть в записи на YouTube или во «ВКонтакте».
Во время вебинара участники задали много интересных и очень разных вопросов – об ИИ-инструментах, безопасности данных, создании и сопровождении тестов, работе с MCP и внедрении автоматизации в CI/CD. На часть из них Александр ответил во время эфира, а остальные вопросы разобрал отдельно после вебинара. В этой статье мы собрали его ответы, потому что каждому из этих вопросов стоит уделить отдельное внимание.
Начнем с вопросов о самой профессии и формате обучения: почему вакансий тестировщиков 1С меньше, чем ожидается, и как устроен учебный ритм.
Насколько востребовано тестирование в 1С? Почему вакансий по этому направлению мало?
Тестирование в 1С востребовано сильнее, чем кажется по числу вакансий.
Исторически им занимались смежные специалисты. Ручное тестирование поручали аналитикам и консультантам, а автоматизацию – разработчикам. Поэтому работодатели часто ищут не отдельного тестировщика, а консультанта, аналитика или разработчика, подразумевая, что проверка функционала тоже войдет в его обязанности.
Есть и высокий порог входа. Для ручного тестирования нужно хорошо знать предметную область и особенности 1С. Для автоматизации этого уже недостаточно: нужны навыки тестирования, программирования и владение инструментами вроде Vanessa Automation.
Последние несколько лет ситуация постепенно меняется. Появляются отдельные команды и вакансии тестировщиков 1С. Особенно заметны на этом рынке бигтехи: у них работает много сильных специалистов по разработке и тестированию 1С и у них в командах роль тестировщика выделяется в отдельную.
Поэтому малое количество вакансий скорее говорит не об отсутствии спроса, а о том, что роль тестировщика в 1С пока часто спрятана внутри других профессий.
Можно ли проходить уроки курса в удобном режиме или необходимо строго соблюдать расписание?
Курс можно проходить в удобном темпе: строгих промежуточных дедлайнов у нас нет. Главное – выполнить все домашние задания до окончания курса, если вы хотите получить сертификат или удостоверение о повышении квалификации.
При этом курс построен в недельном ритме – со вторника по вторник. Каждый вторник проходит вебинар, на котором мы подводим итоги предыдущего блока и начинаем следующий. Желательно к этому моменту выполнить задания прошедшей недели, но небольшие задержки допустимы.
Внутри недели вы сами выбираете удобный график: можно смотреть видео понемногу каждый день или пройти весь блок на выходных. Записи доступны в асинхронном режиме – их можно смотреть в своем темпе, ставить на паузу или менять скорость воспроизведения.
После видеоуроков предусмотрены упражнения «Сделай как я», где нужно повторить действия преподавателя, а затем – домашнее задание. Обычно оно состоит из нескольких частей с возрастающей сложностью: от повторения разобранного примера до самостоятельного решения более сложной задачи.
Поэтому заниматься можно по собственному графику, но для более комфортного и последовательного обучения советуем придерживаться общего недельного ритма.
Какие курсы для продвинутого уровня тестирования у вас есть? Когда планируется курс с программированием?
Курс по тестированию для продвинутого уровня и курс по программированию находятся в разработке. Точных сроков запуска пока нет. Следите за новостями на сайте Инфостарта и в Telegram-канале Инфостарт Обучение
В этом блоке мы ответим на вопросы о стоимости агентов, выборе моделей, работе в закрытом контуре и границах безопасного использования облачных сервисов.
Сколько стоит работа агента?
В моем случае работа агента стоит от $20 до $100 в месяц – в зависимости от выбранной подписки и объема задач. Отмечу, что для разработки автотестов с использованием промптов из поставки Vanessa Automation тарифа за $20 хватит только для совсем небольшого объема задач.
Есть и другие варианты:
- развернуть собственную модель – тогда расходы складываются из стоимости аренды и обслуживания оборудования;
- использовать API с оплатой за токены – pay-as-you-go.
Бесплатные модели я не тестировал, поэтому оценить их возможности не могу.
В текущей реализации агент расходует много токенов на разработку сценариев, поэтому работа через API может оказаться слишком дорогой и даже менее выгодной, чем ручное тестирование. Итоговая стоимость зависит от модели, сложности задачи и качества промптов. Пока решение еще не оптимизировано с точки зрения расхода токенов.
В какой ИИ можно загрузить видео, чтобы получить сценарий?
Любая мультимодальная модель сможет решить эту задачу. Я на вебинаре использовал GPT-5.6 Sol. Другие примеры таких популярных моделей: Google Gemini 2.5 и выше, Moonshot AI Kimi K2.6 и выше. Из открытых моделей решить такую задачу способны Qwen2.5 и выше, GLM-4.6М и выше и многие другие.
Можно ли организовать тестирование и написание тестов под управлением ИИ, если виртуальная машина с базами не подключена к интернету, но в той же локальной сети находится другая виртуальная машина с IDE и ИИ, у которой есть интернет?
Да, такую схему можно организовать: виртуальной машине с базами не нужен доступ в интернет, если она доступна по локальной сети машине с ИИ-агентом. Однако промпты, входящие в поставку Vanessa Automation, сейчас не рассчитаны на такую конфигурацию – их придется адаптировать.
Независимо от места запуска агент будет получать данные из тестируемой информационной базы. Поэтому лучше использовать специально подготовленные тестовые данные. Слепки реальных баз необходимо предварительно обезличить: удалить персональную, контактную и другую конфиденциальную информацию.
Технически компоненты можно разместить на разных физических или виртуальных машинах:
Доступ к MCP по IP и порту
MCP-сервер Vanessa Automation
Доступ к тестовой базе
- ИИ-агент должен иметь сетевой доступ по IP-адресу и порту к MCP-серверу Vanessa Automation, запущенному в Менеджере тестирования;
- Менеджер тестирования должен иметь сетевой доступ к Клиенту тестирования;
- ИИ-агент и Менеджер тестирования должны иметь доступ к общему каталогу с feature-файлами по одному и тому же пути, например по UNC-пути \\server\tests\features.
ИИ-агент записывает feature-файлы непосредственно в этот каталог, а Менеджер тестирования загружает их оттуда и запускает. Если обеспечить общий сетевой каталог и связность между компонентами, агент сможет создавать и выполнять тесты, даже если 1С установлена на другой виртуальной машине без доступа в интернет.
Насколько защищены данные при использовании ИИ?
Если речь об облачных провайдерах, то можно сказать, что в общем случае никак не защищены.
Уровень защиты зависит от того, какие данные получает ИИ и где работает модель.
Рекомендуется по умолчанию всегда использовать только тестовые данные и не передавать ИИ реальные данные из рабочих информационных баз 1С. Если тестовая база создана из копии рабочей, ее необходимо обезличить: удалить персональные и конфиденциальные сведения, а чувствительные значения заменить синтетическими.
При работе с внешними облачными ИИ-провайдерами также нужно учитывать политику информационной безопасности организации и требования законодательства о персональных данных, включая правила трансграничной передачи.
А наибольший контроль обеспечивают локальные модели в изолированном контуре компании.
Как решается вопрос защиты чувствительных данных при загрузке видео для анализа?
Главное правило – не загружать во внешний облачный сервис видео с реальными персональными или конфиденциальными данными.
В моем случае видеоинструкция была записана на тестовых данных, поэтому для ее анализа я мог безопасно использовать облачный ChatGPT. Если же на видео показана рабочая база, безопаснее обрабатывать его локально:
- Транскрибировать видео в субтитры с временными метками.
- Обезличить полученный текст.
- Передать облачному ИИ только обезличенный транскрипт.
Чтобы дополнить инструкцию скриншотами, видео можно локально разложить на кадры с помощью FFmpeg. Затем ИИ на основе временных меток подготовит скрипт, который сопоставит фрагменты транскрипта с нужными кадрами. Само видео при этом загружать в облако не потребуется.
Перед внешней передачей или публикацией скриншотов данные на них также необходимо скрыть или обезличить.
Можно ли локально развернуть квантованную модель и запустить на ее основе агента?
Да, агент может работать на локально развернутой квантованной модели. Например, промпты из поставки Vanessa Automation тестировались на модели Qwen, запущенной локально во внутреннем контуре.
Существуют ли отечественные или открытые аналоги Cursor IDE, которые не требуют VPN, принимают оплату в рублях и работают с моделями, обрабатывающими данные на территории РФ?
К сожалению, отечественные аналоги Cursor IDE и других западных ИИ-агентов с такой же эффективностью мне не известны.
Есть возможность запуска локальных моделей на ресурсах облачных провайдеров, например, у нашего партнера Selectel есть продукт «Foundation Models Catalog», предоставляющий доступ к популярным OSS-моделям, таким как Qwen.
Проводилось ли сравнение работы Cursor, Claude, DeepSeek и ChatGPT?
Нет, пока сравнение не проводилось.
Самый большой блок – о том, как превратить исходную инструкцию в воспроизводимый автотест, какие задачи оставить детерминированной автоматике и где агенту нужны жесткие ограничения.
При внедрении Vanessa Automation много времени уходит на изучение инструмента и написание сценариев, при этом эффективность может быть незаметна. Существуют ли паттерны для оптимизации разных вариантов тестов?
Универсального решения здесь нет: сначала нужно определить, на каком этапе теряется эффективность. На практике больше всего времени обычно уходит на поддержку сценариев. Они ломаются не из-за дефектов, а из-за регулярных изменений функционала или UI, вслед за которыми приходится обновлять тесты.
Чтобы оптимизировать процесс, рекомендуется придерживаться следующих принципов, которые мы разбираем в рамках курса «Автоматизированное тестирование в 1С»:
- Приоритезация функционала: Автоматизируйте только то, что уже зафиксировано и стабильно работает. Избегайте автоматизации блоков, которые находятся в стадии активной разработки.
- Минимизация E2E-тестов: Откажитесь от длинных сквозных сценариев (end-to-end) для динамично меняющихся модулей. Они наиболее подвержены поломкам при малейших правках.
- Регрессионная стратегия: Сосредоточьтесь на покрытии регрессионными тестами критически важных и устоявшихся бизнес-процессов.
- Библиотека шагов проекта: Создавайте и используйте библиотеку общих шагов конкретно под ваш проект. Это позволит при изменении интерфейса обновлять код в одном месте, а не во всех сценариях сразу.
Для чего нужен этап исследования при ручном запуске? Почему нельзя сразу написать тест, опираясь на исходники конфигурации? Какие артефакты должны быть получены после исследования?
Этап исследования отделяет неопределенный поиск пути по интерфейсу от более предсказуемой задачи написания и отладки автотеста.
Исследователь вручную проходит будущий сценарий в клиенте 1С и фиксирует факты, необходимые для автоматизации: путь по интерфейсу, технические имена элементов, подходящие тестовые данные, возникающие окна, результаты операций и возможные блокировки. Сам тест на этом этапе не создается.
Исходников конфигурации недостаточно: они помогают понять бизнес-логику и найти причины ошибок, но не показывают фактическое состояние тестовой базы, влияние прав и функциональных опций, состав динамических форм, заголовки окон и модальные диалоги. Поэтому исходный код используется для диагностики, а не вместо проверки через интерфейс.
Результатом исследования должна стать воспроизводимая спецификация будущего теста:
- очищенная запись действий в Turbo Gherkin;
- перечень форм и элементов интерфейса;
- предусловия и тестовые данные;
- ожидаемые результаты и способы их проверки;
- обнаруженные ограничения и блокировки.
На основе этой спецификации субагент-писатель создает полноценный .feature-сценарий, запускает и отлаживает его.
Как обучить ИИ сравнивать отчет из инструкции с фактическим отчетом? В МИС более 700 отчетов, поэтому проверить их в рамках регрессионного тестирования вручную нереально.
Здесь я бы не стал поручать ИИ-агенту каждый раз формировать и сравнивать все 700 отчетов. Это детерминированная задача, которую надежнее и дешевле решить обычной автоматизацией.
Для каждого отчета нужно сохранить:
- параметры формирования;
- эталонный результат;
- правила сравнения, включая поля, которые могут меняться между запусками.
Далее параметризованный сценарий Vanessa Automation открывает нужный отчет, устанавливает параметры, формирует его и сохраняет результат. Отдельный алгоритм сравнивает результат с эталоном и фиксирует различия. Если отчеты устроены похоже, можно сделать один общий сценарий, а названия отчетов и наборы параметров хранить в таблице.
ИИ здесь полезен на этапе создания этой системы: он может помочь сгруппировать отчеты, подготовить сценарии и параметры, написать код сравнения, а затем разбирать найденные расхождения. Но постоянно поручать агенту нажимать кнопку «Сформировать» и самостоятельно сравнивать каждый результат неэффективно. Кроме высокой стоимости, такой процесс не гарантирует одинакового поведения при повторных запусках.
Если во время написания тестов нейросеть при проведении документа обнаруживает ошибку, например нехватку ОС на балансе, нужно ли писать отдельный промпт с описанием ошибки и просьбой ее исправить? Или нейросеть может зациклиться, пытаясь провести документ?
Если агент работает без специальных инструкций, предсказать его поведение сложно. Он может остановиться, повторять проведение, создать недостающие остатки или подобрать другую номенклатуру. Даже два запуска одной задачи с одинаковой моделью могут дать разные результаты: генерация недетерминирована, а допустимый способ решения заранее не ограничен.
У меня был похожий случай, когда я попросил при помощи ИИ-агента решить одну из задач курса «Автоматизированное тестирование в 1С» – проверку проведения расходной накладной. Агент должен был создать документ, заполнить шапку и табличную часть, провести его и проверить движения. Во время исследования ИИ-агент столкнулся с тем, что товара не хватает. Тогда он самостоятельно оформил оприходование, получил нужный остаток и продолжил сценарий. Другая модель могла бы остановиться или заменить товар.
Именно поэтому в промптах из поставки Vanessa Automation, которые мы разбирали на вебинаре, поведение агентов регламентировано. Исследователю явно запрещено самостоятельно создавать отсутствующие вспомогательные данные или подменять их другими. При наличии подобной проблемы он согласно инструкции промта должен зафиксировать, каких данных не хватает, и пометить сценарий как заблокированный.
При технической ошибке агент анализирует состояние интерфейса и делает ограниченное число повторных попыток. В мультиагентной схеме (examples/МультиАгент) к разбору может подключиться субагент АналитикКода: он изучает доступные исходники и предлагает допустимое решение, но не изменяет конфигурацию или данные. Если проблему решить не удалось, работа останавливается, а человеку передается описание ошибки и условий ее воспроизведения.
Поэтому при использовании этих промтов зацикливание не допускается самим регламентом. Без таких инструкций поведение агента остается непредсказуемым, и дополнительный промпт с явными ограничениями действительно может понадобиться.
Как передать ИИ готовые тесты для их актуализации?
Готовые тесты у вас должны лежать в репозитории проекта в виде .feature-файлов и вам нужно будет только указать агенту путь к ним. Вместе с упавшим тестом нужно передать также актуальные требования и сведения о падении: ошибочный шаг, лог запуска, скриншот и ожидаемый результат. Без этого агент не поймет, устарел тест или изменилось поведение конфигурации.
Промпты «МультиАгент», которые мы рассматривали на вебинаре, рассчитаны прежде всего на создание тестов из ТестПлан.MD, но их можно адаптировать для актуализации существующих сценариев. Пайплайн будет выглядеть так:
Исходники конфигурации могут помочь АналитикуКода найти причину падения, однако он работает с ними только на чтение и не изменяет конфигурацию.
Это еще не готовый механизм self-healing. В разобранных промптах есть роли, ограничения и проверки качества, но нет системы, которая сама отслеживает прогоны и распределяет упавшие тесты. Для полной автоматизации потребуется внешний оркестратор или скрипт, который собирает ошибки, создает задания агентам и принимает исправления только после успешного повторного запуска.
Если видео записано в рабочей базе с одними данными, а тесты создаются в тестовой базе с другими данными, как поведет себя исследователь? Сможет ли он использовать аналогичные элементы справочников и оценивать результаты, отталкиваясь от исходных данных тестовой базы?
Видео служит источником для тест-плана, но сам тест выполняется по требованиям из ТестПлан.MD. Поэтому после разбора видео тест-план нужно адаптировать к тестовой базе: указать доступные данные либо сформулировать критерии их выбора.
В мультиагентном пайплайне еще до Исследователя запускается агент анализа данных и интерфейса. Он проверяет наличие нужных организаций, складов, партнеров, номенклатуры и документов, а затем фиксирует подходящие элементы и обоснование их пригодности.
Если тест-план допускает выбор по признакам, например «любая номенклатура без характеристик», агент может подобрать соответствующий элемент в тестовой базе. Результаты при этом оцениваются относительно ее исходного состояния: Исследователь записывает точные значения до и после операции и проверяет математическую корректность изменений.
Если в тест-плане указан конкретный элемент, которого нет в базе, Исследователь не должен заменять его похожим или создавать самостоятельно. Он фиксирует недостающие данные и помечает сценарий как заблокированный. После этого данные подготавливает администратор тестовой базы либо корректируется сам тест-план.
Для автоматического сопоставления данных можно добавить отдельный этап с явными правилами эквивалентности: какие реквизиты обязательны и какие элементы разрешено заменять аналогами. Без таких правил самостоятельная подмена данных может изменить смысл проверки.
Как организовать процесс, чтобы LLM формировала тесты по созданным в базе документам, если готовых инструкций нет?
Одних документов в базе недостаточно. Они показывают итоговое состояние, но обычно не объясняют цель операции, последовательность действий пользователя и ожидаемый результат. Поэтому сначала потребуется восстановить и зафиксировать требования.
Журнал регистрации и история изменений могут частично восстановить хронологию, если соответствующие механизмы включены, но полного описания бизнес-процесса они не дают.
Самый доступный способ собрать инструкции – попросить опытных пользователей показать свою работу с записью экрана и комментариями. Если в команде есть аналитики или консультанты, хорошо знающие систему, описание процессов можно подготовить вместе с ними.
Полученные материалы следует сопоставить с данными информационной базы, интерфейсом и связанными участками исходного кода. На этой основе формируются сценарии «Дано – Когда – Тогда» и тест-план. После проверки специалистом его можно передать мультиагентному пайплайну для исследования, создания и запуска автотестов.
Можно ли создавать видеоинструкции с помощью ИИ? Может ли ИИ самостоятельно расставить в сценарии паузы и другие элементы, чтобы видео было удобно воспринимать?
Да, ИИ может подготовить сценарий видеоинструкции, включая паузы, акценты и последовательность действий. Для этого нужно заранее описать правила, по которым строится такое видео: уровень детализации, темп, переходы между действиями и требования к подаче материала.
Готового решения в текущей поставке нет. Существующие в поставке Vanessa Automation промпты предназначены для создания сценариев проверки поведения, а видеоинструкции требуют другого формата и структуры.
Реализовать такой процесс можно по аналогии с созданием автотестов:
Технических препятствий для этого нет, но потребуется разработать отдельные промпты или скиллы и описать весь процесс подготовки видеоинструкций.
Если проект длится долго и включает разные технические задания, эффективнее ли сразу создавать общие шаги в первом ТЗ, чтобы затем использовать их в следующих? Или разработка общих шагов с помощью ИИ нецелесообразна и лучше оставлять все действия непосредственно в сценариях?
Общую библиотеку высокоуровневых шагов стоит создавать и развивать независимо от того, создаются тесты вручную или с помощью ИИ. Она формирует единый язык проекта – ubiquitous language – и общий контекст для разработчиков, аналитиков и тестировщиков.
При этом не нужно заранее проектировать всю библиотеку в рамках первого ТЗ. Лучше выносить в общие шаги устойчивые действия, которые уже повторяются в разных сценариях. В TurboGherkin для этого можно и нужно использовать экспортные сценарии.
Так тесты становятся короче и понятнее, а сопровождение упрощается. Например, если в нескольких сценариях используется шаг «Сформировать печатную форму», то после изменения интерфейса достаточно один раз обновить его низкоуровневую реализацию. Все сценарии, использующие этот шаг, продолжат работать без отдельных правок.
Как применять переменные и условия в сценарии теста, сгенерированного ИИ, когда без них невозможно обойтись?
Переменные, условия, циклы и другие конструкции TurboGherkin в сгенерированных сценариях применяются по тем же правилам, что и при ручной разработке: только там, где без них действительно не обойтись, и строго по назначению.
На курсе «Автоматизированное тестирование в 1С» мы подробно разбираем эти конструкции: когда их стоит использовать, когда лучше избегать и как правильно встраивать в сценарии.
Отдельно обучать агента синтаксису не требуется. В поставку входят документация и библиотеки шагов, а MCP-инструменты позволяют агенту искать нужную информацию и применять ее при создании сценария. Однако правила использования переменных, условий и циклов все равно нужно закрепить в промптах и инструкциях агента.
В этой части поговорили о настройке связки Vanessa Automation, MCP, IDE и тестовых баз, а также о подключении собственных библиотек шагов.
Что представляет собой информация об ERP в папке? Работает ли она вместе с промптом? Откуда взять папку по ERP? На каком шаге она подключается к клиенту тестирования?
Отдельной папки с данными ERP нет, и подключать ее к Клиенту тестирования не требуется. Упоминание ERP содержится в шаблонах промптов, потому что они разрабатывались и отлаживались в команде тестирования ERP, где работает их автор Леонид Паутов – автор Vanessa Automation.
Перед использованием промптов достаточно заменить «ERP» на название своего проекта или конфигурации. Например, на вебинаре я с помощью глобального поиска заменил его на «Демо83».
Будет ли инструкция по настройке менеджера тестирования: какое расширение установить, куда его поставить и какие настройки MCP необходимы? Будет ли инструкция по настройке клиента тестирования и VS Code: как установить расширение, связать его с клиентом и внести необходимые настройки? Как получить готовую связку клиента, менеджера тестирования и VS Code?
Да, я подготовил видеоурок с пошаговой настройкой всей связки:
- Менеджера тестирования и необходимых расширений;
- MCP-сервера и его подключения к ИИ-агенту;
- Клиента тестирования;
- VS Code и расширения с ИИ-агентом;
- Взаимодействия всех компонентов между собой.
Посмотреть и скачать его можно по ссылке.
Может ли агент использовать библиотеку ранее написанных пользовательских шагов и расширение RAT?
Да. Для этого нужно предоставить агенту описание ранее созданных пользовательских шагов и возможностей расширения RAT.
Информацию можно оформить отдельным документом и подключить через AGENTS.md либо передать непосредственно в промпте. Таким же способом агенту можно предоставить любую другую библиотеку шагов проекта.
Сможет ли ИИ подключить шаги из расширения RAT и с их помощью корректно формировать контекст тестов на серверных базах? Нужно ли загружать весь репозиторий RAT или MCP позволяет ИИ самостоятельно брать необходимые шаги из библиотеки?
Да, агент сможет использовать шаги RAT, но сейчас он не может самостоятельно получить их из репозитория расширения. Готовой интеграции RAT с MCP пока нет. Ниже описаны два подхода, которые можно реализовать без существенных технических сложностей.
Для работы агенту нужно передать документацию по шагам:
- название и назначение каждого шага;
- параметры;
- описание поведения;
- желательно – примеры использования.
Самое простое – оформить такую документацию в виде MD-файла и указать для агента ссылку на него в AGENTS.md.
Загружать весь репозиторий RAT в контекст не нужно: это неэффективно и расходует много токенов. Лучше разделить документацию по категориям на несколько файлов и подключать только те, которые относятся к текущей задаче.
Оптимальное решение – доработать RAT, добавив в него механизм публикации инструментов для поиска шагов через MCP-сервер onec-client-mcp-devkit, который уже используется в Vanessa Automation. Тогда агент сможет находить нужные шаги RAT по запросу так же, как сейчас выбирает шаги из библиотеки VA.
Серверный контекст будет учитываться, если Менеджер и Клиент тестирования работают с одной информационной базой либо с базами, в которых совпадают конфигурация и необходимые тестовые данные.
Можно ли открыть четыре окна IDE и одновременно тестировать четыре разные базы? Сколько экземпляров MCP для Vanessa для этого потребуется: один или четыре?
Технически можно открыть четыре окна IDE и одновременно тестировать четыре разные базы. Для этого потребуется четыре независимых экземпляра MCP-сервера Vanessa Automation – по одному на каждую связку «агент → Менеджер тестирования → Клиент тестирования → база». Экземпляры можно запустить на одной машине, но на разных портах.
Основная проблема здесь не в MCP, а в интерфейсе Windows. Клиенты тестирования могут перехватывать фокус друг у друга. Из-за этого шаги, которые эмулируют нажатия клавиш или отправляют команды в активное окно,работают ненадежно: действие одного теста может попасть в окно другого.
Я пробовал запускать долгие тесты на отдельном виртуальном рабочем столе Windows, а сам в это время продолжил работать на другом. Но Клиент тестирования не удерживался на выделенном рабочем столе: после закрытия и повторного открытия его окно появлялось на случайном рабочем столе, чаще всего – на том, где я в этот момент работал, и забирало фокус.
Поэтому, если компьютер на время тестирования полностью предоставлен агентам и сценарии не зависят от активного окна, четыре параллельных запуска, скорее всего, будут работать. Если вы хотите одновременно пользоваться компьютером или надежно изолировать тесты друг от друга, лучше разместить каждую связку или хотя бы каждого клиента тестирования на отдельной виртуальной машине.
Финальный блок – о том, какую часть анализа и исправления тестов можно вынести в CI/CD, а где по-прежнему нужно ревью человека.
Можно ли реализовать в CI/CD написание, проверку и корректировку автотестов через Vanessa Automation и ИИ? Можно ли автоматизировать большую часть работы, оставив человеку только ревью? Если да, то как?
Да, большую часть этого процесса можно автоматизировать, оставив человеку финальное ревью.
После тестового прогона CI/CD запускает консольного агента, например Codex CLI, и передает ему репозиторий, отчет Allure, вложения и доступ к Vanessa Automation. Агент получает задачу примерно такого вида:
Для этого агенту можно подключить готовый скилл диагностики и задать последовательность работы:
Основная практическая сложность здесь связана с доступом к LLM из CI/CD. Авторизация по пользовательской подписке обычно плохо подходит для автоматического запуска без участия человека, поэтому чаще приходится использовать API с оплатой по токенам. При большом объеме отчетов, логов и повторных прогонов это может получиться дорого.
Если вынести вопрос стоимости за скобки, технически такой конвейер вполне реализуем: человек формулирует правила и проверяет итоговый merge request, а агент анализирует падения, исправляет тесты и выполняет повторные прогоны.
Применяются ли ревью и анализ упавших тестов, включая flaky-тесты, для поиска решений, которые затем можно реализовать в CI/CD?
Да, результаты упавших тестов мы, конечно же, анализируем, особенно пристально, если падение повторяется или тест ведет себя нестабильно. Цель такого анализа – определить, в чем причина: в тестируемой функциональности, самом сценарии, тестовых данных, окружении или инфраструктуре запуска.
Если обнаруживается повторяющаяся проблема, ее решение имеет смысл переносить в CI/CD. Например, автоматически собирать больше диагностической информации, повторно запускать упавший сценарий, проверять доступность информационной базы и тестового клиента перед стартом, управлять тестовыми данными или отдельно помечать нестабильные тесты.
Если вопрос был о том, используется ли для решения этой задачи ИИ – да, мы используем ИИ для анализа проблем, но это пока не автоматический и не автономный процесс, т.е. ИИ тут используется в формате чата, как дополнительный диагностический инструмент.
Применяется ли в рамках ревью категоризация тестов для релиза?
К сожалению, вопрос не очень однозначный. Если под категоризацией имеется в виду разделение тестов на наборы для разных видов прогонов – например, по критичности или назначению, – то сейчас в рамках ревью отдельную категоризацию тестов для релиза мы не выполняем. При ревью мы прежде всего проверяем корректность и полноту сценария. Но тесты можно размечать тегами по подсистемам, критичности или типу прогона, а перед релизом запускать нужную выборку
Пройти весь путь от первого сценария до CI/CD и тестовых данных мы рекомендуем на курсе «Автоматизированное тестирование в 1С».
Посмотреть программу курса
