Решение по автоматизированной проверке движений документа в Vanessa Automation
В этой статье хочу поделиться своим решением по проверке движений документов. Думаю, что не нужно подробно описывать зачем они нужны. Если уж заинтересуетесь, то можно найти много подробной информации в интернете.
Поэтому совсем немного, напомню, что движения — это определенные записи в регистрах и они формируются при проведении документов в системе 1С. Для наглядности — возьмем, как пример, документ Больничный лист. При создании и проведении документу присваивается уникальный номер и создаются движения (записи) в регистрах. В дальнейшем эти данные могут использоваться для отчетов и пр.
Движение документа Больничный лист
Проблема
Каждый проведенный документ в системе 1С создает записи в регистрах. Количество движений зависит от самого документа и логики, которую в него заложили.
Для проведения тестирования необходимо учитывать все эти факторы. Конечно же стоит задуматься об автоматизации этих проверок и как их реализовать.
Что мы имеем:
Некоторое количество документов в системе.
Каждый отдельный документ формирует определенный набор движений.
В регистрах хранится структурированная информация — и различные документы формируют однотипные движения.
Решение
Для проведения ручного тестирования — можно написать по одному тест-кейсу на создание определенного документа и указать какие движения должны формироваться при проведении. Думаю, этого будет вполне достаточно.
Для автоматизации можно использовать такой же подход — но, можно упростить себе работу. Если движения однотипные — то можно попробовать сделать их проверки унифицированными.
Но, в любом случае на создание и проведение документа нужен отдельный сценарий — т.к. для их создания необходимы различные данные. А вот, для проверки движений уже придумать стандартный подход. Можно сделать отдельные сценарии на каждое движение и в зависимости от документа использовать различный набор таких проверок.
Для реализации такого подхода подойдет такая следующая сценария. Получается, что в одном .feachure файле у нас используется не один сценарий, а целая группа.
Структура .feature файла с несколькими сценариями
Такая структура сценария дает определенные плюсы:
Общая группа переменные, т.е. они работают на все сценарии в группе.
Если один из сценариев завершится неуспешно, то остальные будут выполнятся. Т.е. они получаются независимые друг от друга и в отчете мы получим полную картину о результатах проверки.
Но, чтобы это работало нам нужно использовать глобальную переменную — ссылку на созданный документ. Т.к. локальные переменные из одного сценария не передаются в другой.
Глобальная переменная — ссылка на документ
Сначала объявляем глобальную переменную — записываем в нее ». И когда наш документ создался и провелся запоминаем ссылку на документ и записываем ее КонтекстСохраняемый.
Глобальные переменные сохраняются вне контекста сценария и их необходимо удалять после выполнения нужного нам сценария.
Проверку на создание документа и его проведения — думаю, можно пропустить. Главное, что в итоге в системе проведен документ и мы сохранили его ссылку. Далее приступим к написанию сценария проверки движений. В нем можно выделить 4 части:
1. Открытие документа
2. Запоминание данных
3. Поиск (фильтрация) движения
4. Проверка движения
Первый этап — Открытие документа:
Можно просто открывать документ по ссылке, но есть вероятность того, что при сохранении или проведении документа — появится ошибка. Получится, что документ не будет существовать в системе и проверять его движения бессмысленно. Поэтому стоит добавить условие, на такой случай. Именно поэтому выше сначала создается глобальная переменная с значением ». Т.к. если переменная не будет существовать проверка не сработает корректно. Получится примерно вот так:
Открытие документа
Второй этап — Запоминаем нужные данные из документа (номер, дату создания и пр.)
Запоминание данных
Третий этап — переходим на экран Движений документа. И устанавливаем фильтр по нужному нам Регистру.
Поиск (фильтрация) движения
Формируем шаблон по проверке этой таблицы и вставляем в нее сохраненные ранее переменные. Это удобно сделать через Инструменты — получение всей формы в виде шагов. Также не забываем, что в Vanessa Automation есть удобный редактор таблиц Gherkin (Ctrl + Shift + T) .
Проверка движения
В итоге получаем следующий код для проверки движения:
Сценарий: <Проверка движения №1>
* Открываем документ
Если '"$$ГлобальнаяСсылкаНаДокумент$$" <> ""' тогда
Дано Я открываю навигационную ссылку "$$ГлобальнаяСсылкаНаДокумент$$"
* Запоминаем данные из документа
И я запоминаю значение поля с именем 'Номер' как 'НомерДок'
И я запоминаю заголовок текущего окна как "НаименованиеДок"
И я запоминаю значение поля с именем 'Дата' как 'ДатаДок'
* Поиск (фильтр) движений
И я нажимаю на кнопку 'Движения документа'
Тогда открылось окно 'Движения документа (Горизонтально)'
И я нажимаю кнопку выбора у поля с именем "КомпоновщикНастроекПользовательскиеНастройки"
Тогда открылось окно 'Выводить только'
И я нажимаю на кнопку с именем 'СписокСнятьФлажки'
И в таблице "Список" я перехожу к строке:
| 'Значение' |
| 'Регистр сведений Движения (1)' |
И в таблице "Список" я устанавливаю флаг с именем 'СписокПометка'
И в таблице "Список" я завершаю редактирование строки
И я нажимаю на кнопку с именем 'КомандаОК'
Тогда открылось окно 'Движения документа (Горизонтально)'
И я нажимаю на кнопку с именем 'СформироватьОтчет'
* Проверка движений
И табличный документ "ОтчетТабличныйДокумент" равен:
| 'Движения документа Больничный лист $НомерДок$ от $ДатаДок$' | '' |
| '' | '' |
| 'Регистр сведений "Движения (1)"' | '' |
| 'Стандартные реквизиты' | 'Измерения' |
| 'Активность' | 'Документ основание' |
| 'Да' | '$НаименованиеДок$' |
И я закрываю все окна клиентского приложения
Итог
Подготовлен пример сценария по проверке одного движения документа. Его можно адаптировать под любой другой регистр — поменяв запоминаемые переменные, фильтр, и шаблон таблицы.
Если есть чем поделиться — то пишите, будет интересно узнать о других реализациях проверки движений документа.