Добрый день! В этой статье рассмотрим вариант по автоматизированной проверке расчетов с использованием инструмента Vanessa automation.

Добрый день. В этой статье хочу порассуждать о тестировании печатных форм на платформе 1С с помощью инструмента Vanessa Automation.

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

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

Поэтому совсем немного, напомню, что движения — это определенные записи в регистрах и они формируются при проведении документов в системе 1С. Для наглядности — возьмем, как пример, документ Больничный лист. При создании и проведении документу присваивается уникальный номер и создаются движения (записи) в регистрах. В дальнейшем эти данные могут использоваться для отчетов и пр.

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

Всем привет! Меня зовут Пётр и это моя первая статья.

Занимаюсь функциональным и интеграционным тестированием на проекте 1С. И решил попробовать свои силы в автоматизированном тестировании — чтобы упростить себе жизнь. И на текущий момент около года работаю с инструментом Vanessa Automation и решил поделиться своим решением для проверки XML сообщений. К нему я пришел не сразу — пришлось экспериментировать, чтобы найти рабочий подход для таких проверок.

Проблема

Уверен, что многие кто тестировал XML сообщения — знают, что такие проверки довольно сложные. Потому, что в сообщениях передаются много разнообразных параметров и сами сообщения могут быть очень большими. Также стоит добавить определенную логику заполнения XML сообщений и то, что может быть несколько различных потоков (типов сообщений) и мы получим довольно объемный набор тест‑кейсов.

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

Постановка задачи

Чтобы понять как решать задачу — нужно сначала ее сформировать.

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