Разработка и сценарное тестирование с Vanessa-ADD. Концепция, теория и сквозной пример создания сценария

В 2012 году вышла платформа 8.3.2 в которой появилась возможность запуска платформы 1С в режиме тест-клиента и тест-менеджера. Думаю большинство из тех, кто тогда попробовал пройтись по теперь уже древней инструкции https://its.1c.ru/db/metod8dev/content/5011/hdoc мог сделать вывод, что использование этих механизмов очень трудоемко. Тогда это была простыня XML или её аналог в виде кода 1С. "Наиболее вероятно это сделали для развития на мобильниках или какой-то задел на будущее" - так можно было сказать.

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

Вот список наиболее известных инструментов :

1) Сценарное тестирование из состава "Корпоративного инструментального пакета" https://its.1c.ru/db/kip/content/66/hdoc.

2) Тестер http://www.test1c.com и //infostart.ru/public/642946

3) Конфигурация "Тестирование 3.0" : https://github.com/ivanov660/TestingTool-3/wiki

4) Vanessa-ADD (Automation Driven Development) - https://github.com/silverbulleters/add - результат объединения проектов xUnitFor1C и Vanessa-Behavior, о котором пойдет речь дальше.

5) Vanessa-Automation : https://habr.com/post/418303 , https://github.com/Pr-Mex/vanessa-automation. Проект также является наследником Vanessa-Behavior, ориентированным в том числе на совместное применение с СППР. Развивается параллельно с Vanessa-ADD. Пока информации по возможностям СППР в этом плане мало, но возможно скоро появится тема для отдельной публикации по этим инструментам.

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

Конечно, хотелось бы быть корректным и похвалить каждый из этих инструментов (ага, даже не попробовав каждый из них ;)), однако факты таковы, что наибольшее распространение сегодня получили инструменты основанные на Vanessa-Behavior и языке Gherkin (читается как Геркин). Во многом это произошло благодаря активности авторов в продвижении этих инструментов и организации сообществ разработчиков вокруг них. Также во многом благодаря возможности выбора между подходами: работать по BDD или просто покрывать функционал тестами. Тот, кто следит за ситуацией вокруг этой темы и публикациями на ИТС, знает, что они начинают применяться даже при разработке тиражных решений в фирме 1С.

Хотя, на удивление, именно эти инструменты обладают наименее структурированной документацией и информацию по ним приходится собирать по кусочкам. “Мне целый год пришлось ковыряться чтобы как-то начать применять”, “Вам бы сквозной пример сделать” - приходилось читать такое про Ванессу. Да и не скрою, самому испытывать похожие эмоции в начале знакомства с этим представителем чешуекрылых. Но это чувство обманчиво. Примеров и материалов, в том числе видеоматериалов, на самом деле много. Достаточно вбить ключевые слова в поисковик или на Гитхаб, чтобы в этом убедиться. Не структурировано? Да. Мало? Нет.

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

Для примеров применения будет использоваться демонстрационная база 1C: Управление торговлей 11.4.

Чем сейчас является Vanessa-ADD?

1) Это результат объединения двух фреймворков для тестирования и разработки по BDD и последних шагов сообщества разработчиков по унификации подходов к тестированию: xUnitFor1C (дымовое и юнит-тестирование) и Vanessa-Behavior (сценарное тестирование и BDD). Ранее эти инструменты распространялись отдельно, хотя между ними и была небольшая зависимость.

Проект является открытым, как для использования, так и для участия в разработке : https://github.com/silverbulleters/add

2) Это библиотека OneScript и устанавливается она также как и любая другая библиотека OneScript. Например командой opm install add. А еще лучше opm install -all. Весь каталог OneScript со всеми библиотеками занимает около 50 МБ и сложно найти причину чтобы не установить весь комплект библиотек целиком.

Поставка xUnitFor1C и Vanessa-Behavior в виде одной библиотеки - это очень удобно для пользователей OneScript. Кроме того, теперь расположение инструментов стандартизировано, мы всегда знаем, что нужные обработки находятся в каталоге OneScript/lib/add (в случае установки на Windows по умолчанию в каталоге C:\Program Files (x86)\OneScript\lib\add) На мой взгляд это способствует усилению экосистемы OneScript и упрощению работы с другими библиотеками.

К слову сказать это не единственное важное упрощение и объединение, произошедшее в экосистеме OneScript. Почти одновременно с этим функционал инструмента для развертывания deployka перекочевал в vanessa-runner. Команды стали красивее, пользоваться стало проще. Для управления сессиями на сервере 1С , конфигуратором, запуском клиентов 1С, запуском Vanessa-ADD теперь достаточно одной базовой команды runner или vanessa-runner.

Но взаимодействие Vanessa-ADD и Vanessa-Runner - это пожалуй тема для отдельной публикации, а желающие разобраться с вопросом автоматического запуска через vanessa-runner могут уже сейчас обратиться к документации в репозитории : https://github.com/silverbulleters/vanessa-runner

К чему нужно быть готовым?

Это Open Source проект. Со всеми достоинствами и недостатками этой модели разработки.

Встретившись с неадекватным сообщением, требующим заполнить поле, которое не ясно где искать, с этим придется смириться и самостоятельно найти поле. Пусть даже для этого нужно облазить весь интерфейс и не найти поля именно с таким наименованием )) Не нужно ругаться, что разработчики использовали старый метод Сообщить() вместо объекта СообщениеПользователю с указанием поля. Х~~отя можно и погураться, если сами этим никогда не грешите :)~~

Обнаружив какой-то недостаток лучше создайте Issues на гитхабе. Или помогите с доработкой. Н~~о мы то знаем что удобнее всего просто привыкнуть к недочетам и ждать пока их другие за нас устранят~~.

Да, есть интерфейсные недочёты. Многие библиотечные шаги (проще говоря код на Gherkin) звучат одинаково, хотя имеют разный смысл. Кое-где код написан "~~на отвали"~~ в спешке. Но всё это с лихвой компенсируется возможностями фреймворка. И тем, что при желании можно внести в него изменения, в том числе с целью рефакторинга, сделав свой форк на гитхабе, пул-реквест в основной репозиторий, или просто написав свою библиотеку шагов.

Если же помогать проекту не собираемся или не знаем как, то берем и пользуемся, постепенно проникаясь возможностями инструмента. Вооружившись таким настроем можно приступать к работе с Vanessa-ADD ))

Что мы хотим получить?

Vanessa-ADD и язык Gherkin могут помочь команде разработки как минимум по трем направлениям

Постановка задач на разработку.
Регрессионное тестирование.
Демонстрация реализованного функционала.

Gherkin - это язык описания поведения. Изначально он создавался в рамках проекта Cucumber для BDD (Behavior Driven Development), а в BDD сценарий написанный на этом языке является частью спецификации на функционал и средством общения между постановщиком задач и разработчиком. В этой же роли он может выступать и сейчас при разработке в 1С. И слово "Разработка" в заголовке этой публикации относится именно к такому варианту применения Gherkin и Vanessa-ADD. Один из примеров такого подхода будет рассмотрен ниже с иллюстрациями. А прямо сейчас ознакомиться этой идеей можно зайдя на сайт проекта Cucumber : https://cucumber.io

Сценарий, написанный на языке Gherkin и сохраненный в feature-файле может быть открыт с помощью Vanessa-ADD в менеджере тестирования, а затем проигран в клиенте тестирования. Клиент тестирования внешне ничем не отличается от обычного клиентского режима запуска 1С. Это позволяет использовать созданные сценарии для демонстрации возможностей системы или разработанного функционала. По крайней мере для предварительной демонстрации - показать как система работает, а затем уже повторить часть действий вручную, там где это требуется. Наибольшую пользу это должно приносить при применении BDD, когда сценарий выступает в роли спецификации и его проигрывание демонстрирует, что функционал удовлетворяет этой спецификации. В этом случае мы получаем такую уникальную вещь, как “исполняемая документация”.

На теме регрессионного тестирования хотелось бы остановиться подробнее.

Обычно, когда мы в области 1С говорим про тестирование выполненной задачи, мы имеем в виду приемочное тестирование (UAT, user acceptance testing) - проверку того, насколько новый функционал соответствует требованиям заказчика. Приемочное тестирование выполняется в рамках какой-то отдельной задачи и нового функционала, решающего эту задачу. При этом, как правило, не выполняется проверка каждого закоулка системы на предмет того, не ломает ли новый функционал уже существующие блоки системы. Если пользователь доволен новым функционалом - значит задачу можно закрывать. При этом жертвой могут стать пользователи совсем других блоков системы.

Конечно если за приемку задачи ответственен ИТ-специалист (аналитик, консультант, QA-инженер), то он может предположить с каким ранее реализованными блоками системы связан новый функционал и проверить их также. Но всё же найти ошибку в смежных блоках системы при приемочном тестировании - это скорее удача, чем закономерность. Предположения о возможных поломках часто оказываются неверными. В наших 1С-ных системах это ведет к срочным динамическим и нединамическим обновлениям продуктовых баз после нового релиза.

Для безответственных или не имеющих ресурсов на качественную разработку ИТ-служб, которых в настоящее время большинство, это считается нормальной ситуацией. Всегда можно спихнуть с себя ответственность и прикрыться лозунгом “это же 1С” или “это же Agile, нам главное скорость”. Но для ИТ-служб, отвечающих за комфорт и непрерывную работу своих пользователей и имеющих на это ресурсы, инструментом в борьбе за качество системы становится целенаправленное регрессионное тестирование.

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

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

Рост трудозатрат с ростом системы. Независимо от того насколько быстро меняется система, каждый новый функционал приводит к добавлению в список необходимых проверок новый тест-кейс.
Нестабильность проверок. Сложно запомнить всё, что нужно проверить, и повторить полный объем проверок в точности, как это выполнялось в прошлый раз. Это достаточно сложно даже если тест-кейсы зафиксированы в документации.
Ручное регрессионное тестирование - это рутина, которая убивает внимательность и мотивацию.
Рост частоты проверок с учащением релизов. Что вместе с нестабильностью проверок повышает вероятность ошибок и недочетов в самом процессе тестирования.

Собственно уже здесь мы видим заявку на автоматизацию. И автоматизация регрессионного тестирования действительно является стандартом в отрасли разработки ПО : https://ru.wikipedia.org/wiki/Регрессионное_тестирование

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

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

Автоматизация регрессионного тестирования через написание сценариев всё же обладает одним важным недостатком: большой объем трудозатрат на адаптацию сценариев к изменениям блоков системы, проверяемых этими сценариями. Чем чаще меняется покрытый тестами блок системы, тем дороже становится адаптация.

Это особенно критично в мире 1С, где смена редакции типовой конфигурации может приводить к большим изменениям в интерфейсах и логике работы типовых объектов и при переходе на новую редакцию придется адаптировать не только наш код внутри конфигурации, но и сценарии для Vanessa-ADD. Усугубляется это и тем, что многие шаги сценариев в Vanessa-ADD привязываются не просто к интерфейсным текстам, а к именам элементов форм, как они заданы в конфигураторе. При нехватке ресурсов на адаптацию тестов к изменениям в конфигурациях оно может стать “консервирующим” фактором, мешающим обновлению типовой конфигурации. Или просто произойдет отказ от автоматизации и ресурсы на начало внедрения автоматизации тестирования будут потрачены впустую.

Общий вывод такой. Автоматизированное тестирование, в том числе сценарное, тем выгоднее, чем чаще реализуется новый функционал и, в то же время, чем реже меняется реализованный ранее функционал.

Поэтому плохо проработанные и постоянно меняющиеся участки системы покрывать тестами будет дорого и надо оценивать стоит ли оно того исходя критичности этих участков для бизнеса. Аналогично нужно относится к покрытию тестами типового функционала, который может быть переработан в новой редакции типовой. Важные бизнес-процессы обязательно должны быть покрыты тестами, даже если их писали не мы, а разработчики типовых конфигураций. При принятии решения относительно остальных блоков системы лучше оценивать хватит ли рабочих рук на адаптацию тестов. В конце концов на помощь можно призвать более простые дымовые тесты xUnitFor1C (а теперь Vanessa-ADD), которые по словам авторов дают до 7% покрытия кода.

Описываем и тестируем только пользовательское поведение

Тот кто знаком с методикой APDEX в применении к 1С помнит, что в определении ключевой операции говорится, что оно начинается и заканчивается на клиенте. Хотите проверки исключительно серверных операций? Вам в другое место!

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

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

Хотим проверить регламентное задание? Пожалуйста! Надо преобреобразовать его во что-то ощутимое, связать с поведением пользователя. Например написать сценарий на запуск из рабочего места управления регламентными заданиями. Определить максимальное время выполнения. Ожидать завершения в течении этого времени и выдавать ошибку по истечению лимита времени.

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

Преимущества сценарного тестирования с Gherkin и Vanessa-ADD

В плане работы по BDD преимущества очевидны: Gherkin является стандартом и Vanessa-ADD воплощает работу с этим стандартом для платформы 1С. Более того, используется расширение языка, которое увеличивает его возможности и в справке по инструменту называется Turbo Gherkin. Подход BDD будет рассмотрен далее. Сейчас рассмотрим плюсы в приложении к сценарному тестированию.

1) Близость к человеческому языку.

Результатом создания сценарного теста с применением ADD является текст сценария на языке Gherkin. Это человекочитаемый язык, развившийся в рамках проекта Cucumber и впоследствии адаптированный к другим системам и другим “человеческим” языкам, в том числе к русскому. Отличная компания для русского варианта встроенного языка 1С!

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

2) Ещё ближе к человеческому языку!

Автоматически создаваемый в Vanessa-ADD сценарий уже можно читать не зная программирования. Но можно (и даже нужно) пойти и дальше за счет средств группировки/декомпозиции шагов, благодаря использованию расширения языка Turbo Gherkin. Несколько логически связанных шагов можно объединять в группы.

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

3) Понимание для кого и для чего создан функционал, под какими ролями его проверять

Каждый сценарий на языке Gherkin начинается с такой замечательной вещи, как пользовательская история (User Story) :

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

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

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

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

4) Дымовые тесты "из коробки".

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

В составе Vanessa-ADD уже идет комплект дымовых тестов https://github.com/silverbulleters/add/tree/master/tests/smoke , которые можно произвольным образом дополнять своими тестами, реализованными в виде внешних обработок для 1С: Предприятия.

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

5) Информативные и полезные результаты выполнения сценариев

Результатом исполнения сценариев в Vanessa-ADD являются :

Отчетность в различных форматах: jUnit, Cucumber, Allure.
Скриншоты, либо каждого окна, либо скриншот снятый в момент возникновения ошибки. Скриншоты могут являться частью отчетности и выполнении сценариев.
Автоматическое формирование “черновиков” пользовательских инструкций в форматах HTML, Markdown.

Наиболее информативной и полезной для целей тестирования является отчетность в формате Allure.

Красивые графики и возможность фильтрации результатов тестирования может произвести “вау-эффект” на пользователей, но только до тех пор, пока падающих тестов много ))

Когда система тестирования налажена и 99% тестов проходят успешно, зеленый квадрат с тонкой красной полоской перестает быть информативным. Он выглядит как сплошная заливка и не дает понимания как прошло тестирование. Например скриншот ниже сделан после того, как тот же CI-контур был стабилизирован. Нормальной является ситуация когда все тесты проходят без ошибок, а если тесты и падают, то в небольшом количестве. На графике красным выделены "всплески", которые говорят об упавших тестах. Но они почти не заметны и поэтому на показания графика сложно ориентироваться :

Аналогично тренд выглядит в отчете Allure :

В этом случае нужно обращать внимание на другие индикаторы. Благо в отчете Allure они также есть - как численные показатели, так и подробные отчеты по дефектам. Ну и оповещения на почту/мессенджер также лучше настроить, любой сервер сборок это позволяет:

Обзор языка Gherkin и структура фича-файла

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

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

В идеале фича - это максимально независимое качество системы, обладающее самостоятельной ценностью. В этом плане оно похоже на пользовательскую историю (User Story) но при этом описывает не только потребность, но и воплощение этой потребности в системе. Более того, правильно созданный фича-файл обязательно содержит в составе пользовательскую историю - описание потребности, которая решается функционалом. И только затем сценарий поведения системы, соответствующий этой пользовательской истории.

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

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

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

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

В дополнение к написанному в этой публикации материалу на русском ознакомиться с Gherkin можно здесь https://wellbehaved.readthedocs.io/Gherkin.html или например здесь https://www.liveinternet.ru/community/rss_rss_hh_new/post417853947/.

Структура фича-файла

Например тег @tree для Vanessa-ADD означает, что сценарий содержит шаги, декомпозируемые на подшаги. Фактически это специальная инструкция, говорящая что необходимо задействовать расширение языка Gherkin. В этом случае если текст шага начинается с отступа (табуляции или пробелов) относительно вышестоящего шага, то он воспринимается не как самостоятельный шаг, а как часть вышестоящего шага.

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

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

Поведение делится на контекст (предысторию) и сценарии.

Контекст (Предыстория) - это условия, которые должны быть выполнены перед каждым сценарием. В случае Vanessa-ADD контекст будет заново выполняться перед выполнением каждого сценария. Таким образом контекст - это общая начальная часть каждого сценария. И без него можно обойтись, если поместить все те же самые шаги в начало каждого сценария. Но опять же, так делать не нужно ))

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

Сценарий, как и контекст, состоит из шагов. Также их называют сниппетами (snippet).

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

Также фича-файл может содержать комментарии, которыми можно воспользоваться либо для подробного описания содержимого файла или шагов, либо чтобы временно отключить шаги. Первой строкой в фича-файле должен быть комментарий специального вида, определяющий вариант языка Gherkin, который применяется в файле. Например #language: ru означает, что в файле применяется русский вариант языка.

Каждая строка комментария должна начинаться с символа #. Для редактирования сценариев совместно с Vanessa-ADD обычно применяется Visual Studio Code, в котором для комментирования/раскомментирования нескольких строк сразу можно выделить эти строки и нажать контрол с точкой Ctrl + .

Это сочетание клавиш универсально и в зависимости от того с каким языком программирования ведется работа в VSC строки будут предваряться характерным для этого языка комментарием. Например при редактировании скриптов OneScript, написанных на языке 1С, в начало строк будет добавляться // вместо символа решётки.

Ключевые слова языка Gherkin

Ключевые слова языка можно разделить на верхнеуровневые и слова, предваряющие сниппеты.

Верхнеуровневые записываются с двоеточием

Функционал:

Функциональность:

Сценарий:

Контекст:

Предыстория:

Ключевые слова шагов без двоеточий являются полностью взаимозаменяемыми. Можно употреблять одно вместо другого. Но не нужно )) Эти слова хоть все и означают начало шага, но служат для того чтобы человеку было удобно и понятно читать сценарий. К ним относятся например следующие слова :

Когда

Тогда

Дано

Пусть

Но

С полным списком ключевых слов можно ознакомиться здесь https://github.com/cucumber/cucumber/blob/master/gherkin/gherkin-languages.json#L2629 (спасибо Леониду Паутову за дополнение и ссылку).

В каком случае применять то или иное ключевое слово? Для этого достаточно помнить о правилах родного языка и включать логику. Рассмотрим каждое из приведенных выше слов.

Дано, Пусть - это шаги которые говорят о том, что система находится в описываемом шагом состоянии. Либо приводится в описываемое состояние этим шагом. Такие шаги больше всего подходят для блока Контекст. Например :

Дано  В базе нет характеристики номенклатуры с наименованием “Белые, размер 43”

Дано  На остатках есть номенклатура “Тестовый товар”

Когда - это шаги, обычно интерактивные, описывающие действия, приводящие к результату, описываемому следующим шагом, начинающимся со слова "Тогда"

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

Когда Я нажимаю на кнопку “Зарезервировать” - действие

Тогда появилось окно с сообщением о нехватке товара - результат действия, истинность которого можно проверить

И, Но - это шаги, которые по смыслу (предлогами) связаны с предыдущими шагами.

Когда Я нажимаю на кнопку “Зарезервировать”

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

Тогда появилось окно с сообщением о нехватке товара

И кнопками, позволяющими выполнить перенести резерв с другого документа

Также в используемом расширении языка есть ключевое слово Если, позволяющее использовать условия, и возможность использовать циклы.

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

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

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

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

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

Зачем нужны эти "Я"?

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

Вместо

        Функционал:   Загрузка начислений из файла

                Как бухгалтер-расчетчик

                Я хочу иметь возможность загружать начисления из файла Excel в документ начисления зарплаты

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

Можно написать

        Функционал:   Загрузка начислений из файла

                В системе необходима загрузка из файла Excel в документ начисления зарплаты

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

Система это пропустит. Но методически правильно писать именно с “Я”. Причины для этого можно назвать как минимум две.

Первая : шаги, после ключевого слова содержащие "Я" означают интерактивное действие. Действие самого пользователя, а не автоматическое действие системы или автоматическую проверку условия.

Когда Я нажимаю на кнопку “Зарезервировать” - интерактивное действие

Тогда появилось окно с сообщением о нехватке товара - автоматическое действие

Тогда Я нажимаю на кнопку “Перенести резерв товара с другого документа” - интерактивное действие

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

Различие между подходами: BDD или покрытие тестами

Vanessa-ADD и родственные ей инструменты позволяют делать выбор между подходами: работать по Behaviour Driven Development или просто писать сценарные тесты для их автоматического запуска и проверки поведения системы. Разница примерно такая же как между Test Driven Development и покрытием юнит тестами.

Здесь хотелось бы попросить понимать разницу между этими подходами. В среде 1С и среди начинающих специалистов из других ИТ-направлений распространена подмена понятий, когда покрытие существующего функционала модульными тестами называют TDD, сценарное тестирование называют BDD, CI/CD тождественно приравнивают к DevOps, абсолютно любую итеративную разработку называют Scrum или Agile. Или вообще считают это всё изобретением буржуйского запада, мешающим нормальным мужикам работать и получать бабло от ИП “Тётя Маня” и ООО “Газмяс” )) Всё же хотелось бы видеть корректное применение терминологии среди коллег и верить, что мы не только автоматизируем компании за бабло, но и являемся инженерами.

TDD говорит о том, что модульный тест (юнит тест), которому должен удовлетворять модуль (объект, метод) пишется до того как написана реализация программного модуля. Максимум, что может быть описано одновременно с тестом - это интерфейс - сигнатура метода, интерфейс объекта. Первый запуск теста обязан "упасть" - подтвердить, что текущая реализация не работает.

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

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

И в том и в другом случае количество кода, создаваемого программистами сильно увеличивается, стоимости разработки растет в начале но компенсируется сокращением сроков на развитие, отладку, тестирование, рефакторинг и поддержку.

Уже чувствуете неприменимость TDD на проектах с коротким сроком и демпинговым бюджетом, за которые разработчики перестанут нести ответственность после его реализации и передадут его на поддержку внутренней ИТ службе заказчика? )) Ведь в этом случае никакой рефакторинг или развитие в расчет не берется. А если они потребуются, то это будет новый проект, и чем он будет затратнее тем иногда выгоднее исполнителю. Правда в сфере 1С за это вообще можно не переживать, у нас и средств для этого удобных нет ))

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

Но в отличие от TDD, где речь идет лишь о коде и взаимодействии программиста и кода, в BDD речь идет о поведении пользователя в системе и о постановки задачи разработчику бизнес-аналитиком. Или о совместной проработке спецификации бизнес аналитиком и программистом. При этом сценарии, описывающие поведение пользователя и смотрящие на систему глазами пользователей, опираются не на интерфейс метода, не на сигнатуру функции, а на пользовательский графический интерфейс приложения. Короткая, но хорошая публикация на эту тему : https://dannorth.net/2012/05/31/bdd-is-like-tdd-if , комментарии к публикации тоже стоит почитать.

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

Кроме того большая часть элементарных шагов в Vanessa-ADD записывается автоматически, получая данные из тест-клиента и преобразуя их в код Gherkin. Для этого мало иметь полноценный интерфейс. Нужен еще программный код, открывающий новые окна, заполняющий их нужными для продолжения записи сценария данными. Иначе мы лишаемся возможности автоматической записи. И все шаги вида "Тогда открылось окно ‘Приобретение товаров и услуг №0000023929 от 24.08.2018 (создание)’" придется писать вручную, а это очень большой неоправданный труд, особенно при наличии возможности автоматической записи.

Разработав же интерфейс и часть работающего с ним кода мы идем по пути отличному от “Сначала сценарий, потом код”. Мы сначала делаем прототип, корректно работающий код и интерфейс, и только затем приступаем к записи сценария. Это уже не столько BDD, сколько покрытие функционала тестами и формирование сценария-спецификации после первоначальной реализации функциональности в системе.

Отсюда вывод. Если мы хотим использовать BDD с применением Vanessa-ADD то лучше не воспринимать исходный сценарий как готовый тест. Его нужно воспринимать именно как спецификацию или часть спецификации (в дополнение к ТЗ, BPMN-схеме или чему-то еще). Эта спецификация может содержать подробное описание поведения пользователя в системе. Функциональность, которую реализует разработчик, должна удовлетворять этой спецификации. Проверить же это может и человек, не обязательно автоматика. После того как функциональность создана можно дополнить исходную спецификацию элементарными шагами, воспользовавшись возможностью декомпозиции шагов. Мы превращаем исходные шаги в группы шагов, а под ними с отступом пишем элементарные шаги.

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

В итоге получаем такую последовательность :

1) Фича-файл с пользовательской историей и подробными сценариями, описанными в терминологии прикладного решения, бизнес-аналитики и бизнес-процессов.

2) Прототип или полноценная реализация функциональности в нашей системе.

3) Автоматическая запись элементарных шагов - "простыни кода на Gherkin" - в работающей системе на основе исходного сценария.

4) Разбивка полученного кода на логические блоки в соответствии с исходным сценарием и встраивание этих блоков в исходный сценарий.

5) Готово! Мы имеем фича-файл, являющийся одновременно и спецификацией и сценарным тестом.

Посмотрим как это можно сделать на практике.

Разработчик и/или бизнес-аналитик пишут фича-файл, реализующий потребность пользователя.

Функционал:  Ввод реализации товаров на основании предварительного созданного заказа клиента



Как менеджер по продажам

Я хочу иметь возможность вводить реализацию товаров на основании ранее оформленного заказа покупателя

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



Контекст:

     В системе существуют свободные остатки по товару “Заказанный товар 1” и Заказанный товар 2”

     И система запущена под пользователем “Менеджер по продажам” с соответствующими ему ограничениями

     И в системе создан и открыт заказ клиента с этими товарами и услугой “Услуга 1” и заданными ценами и количеством



Сценарий:  Проведение реализации вводом на основании из формы заказа клиента        

     Я нажимаю кнопку ввода на основании выбирая из меню Реализацию товаров и услуг

     Тогда открывается форма нового документа Реализация товаров и услуг

     И в этой форме автоматически заполнен товарный состав под данным заказа, цены и количество и склад совпадает с заказом

     И нажимаю на кнопку Провести и закрыть

     Тогда реализация товаров успешно проводится. Под этим понимаем закрытие окна реализации без сообщения об ошибках

Получаем такой файл:

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

После реализации функционала мы получаем возможность записать исполняемый Vanessa-ADD код :

Теперь можно объединить исходный сценарий-спецификацию и полученный сценарий, записанный "кнопконажималкой" в единый файл.

Замечательно то, что используя средства того же Visual Studio Code он сворачивается до исходных шагов и его по прежнему можно воспринимать как спецификацию. А благодаря наличию элементарных исполняемых шагов он может быть исполнен как сценарный тест и в случае необходимости часть его шагов может быть перезаписана всё той же кнопконажималкой:

Кто пишет сценарии?

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

1) В случае подхода BDD это совместная работа представителя заказчика (аналитика, консультанта, продакт-оунера) и разработчика.

На начальном этапе разработки спецификации можно обойтись и без разработчика, но лучше не надо )) Очень часто даже хорошие аналитики/консультанты плохо представляют себе все интерфейсные возможности платформы и могут создать правильный с прикладной точки зрения сценарий, но по которому пользователю придется накачивать руки мышью и клавиатурой сильнее чем в спортзале. В то время как адекватное применение возможностей управляемого интерфейса избавит пользователей от этого. А если у вас есть правильный программист, то он знает как правильно применять возможности управляемого интерфейса. Это ведь его обязанность )) В общем, это подобно выбору : писать техническое задание на разработку с привлечением программиста или без него. Второй вариант можно выбрать либо из-за безрассудства либо если с программистом получится хуже (но тогда и никакой BDD не поможет ;))

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

2) В случае покрытия тестами существующего функционала создание сценария - это совместная работа программиста и QA.

Почему во этом случае также требуется программист? Дело в том, что многие шаги требуют привязки к именам элементов как они заданы в конфигураторе. Даже используя встроенный в Vanessa-ADD исследователь форм (информация о нём будет в следующей публикации) не всегда можно быстро узнать имя. Многие шаги вообще приходится реализовывать самостоятельно. Например в Vanessa-ADD есть шаг для удаления элемента справочника, но нет шага для удаления документа. А свои шаги реализуются через программирование. Ну и наконец при изменении функциональности крайне важно, чтобы разработчик был инициатором изменения сценария. Иначе адаптация сценариев под изменения системы будет пробуксовывать, а накопив большое количество неактуальных сценариев есть шанс вообще убить сценарное тестирование на проекте и потом задаваться вопросом "стоило ли начинать".

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

Возьмем тот же самый сценарий и пойдем обратным путем. Представим, что у нас уже есть готовый функционал, описанный выше (в этом демонстрационном примере он ведь действительно есть в типовой УТ/ERP).

Этот функционал критичен для нашей компании и мы не хотим, чтобы он когда-либо был поломан. Допустим мы не работаем по BDD, но мы хотим чтобы клиенты оставались довольными. Мы даже готовы отложить выпуск новой фичи для бабы Мани, если ее реализация ломает нам продажу по заказу. И мы принимаем решение покрыть этот функционал тестом, который затем будем запускать перед каждым релизом или после каждого коммита в хранилище.

Посмотрим как это делается. Сейчас мы не будем рассматривать установку инструментов. Это тема следующей части публикации. Давайте просто посмотрим на пример создания сценария в установленной Vanessa-ADD “от и до”.

Запускаем Vanessa-ADD и начинаем запись действий пользователя. Сначала запишем все действия под полными правами, а затем организуем проигрывание сценария под пользователями с ограниченными правами :

Что происходило во время записи:

1) Все поля заполнялись вручную путем ввода полных наименований элементов. Это необходимо для определенности, чтобы избежать в тексте сценария обрубленных шагов вида “И из выпадающего списка "Организация" я выбираю по строке 'Тор'”

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

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

4) После формирования реализации товаров на основании заказа мы прокликали каждую строку. Зачем?

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


И в таблице "Товары" я перехожу к строке:

| 'Вид цены'       | 'Количество' | 'НДС'   | 'Номенклатура' | 'Ставка НДС' | 'Сумма'  | 'Сумма взаиморасчетов' | 'Сумма с НДС' | 'Характеристика'                   | 'Цена'   |

| '<произвольная>' | '1,000'      | '76,27' | 'Услуга 1'     | '18%'        | '500,00' | '500'                  | '500'         | '<характеристики не используются>' | '500,00' |

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

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

В итоге получаем такой “сырой” и пока избыточный текст :

#language: ru



Функционал: <описание фичи>



Как <Роль>

Я хочу <описание функционала>

Чтобы <бизнес-эффект>



Контекст:

        Дано Я запускаю сценарий открытия TestClient или подключаю уже существующий





Сценарий: <описание сценария>



        И В командном интерфейсе я выбираю 'Закупки' 'Документы закупки (все)'

        Тогда открылось окно 'Документы закупки (все)'

        И в таблице "СписокДокументыЗакупки" я нажимаю на кнопку с именем 'Создать_ДокументЧерезФормуВыбора'

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

        И в таблице "ДеревоПоДокументам" я перехожу к строке:

                | 'Представление'                                                                                        |

                | 'Приобретение товаров и услуг                                                                        ' |

        И в таблице "ДеревоПоДокументам" я разворачиваю текущую строку

        И в таблице "ДеревоПоДокументам" я перехожу к строке:

                | 'Представление'        |

                | 'Закупка у поставщика' |

        И в таблице "ДеревоПоДокументам" я выбираю текущую строку

        И Я закрываю окно 'Создание документа по хозяйственной операции'

        Тогда открылось окно 'Приобретение товаров и услуг (создание)'

        И из выпадающего списка "Поставщик" я выбираю по строке 'Ассоль'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И из выпадающего списка "Контрагент" я выбираю по строке 'Ассоль'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И из выпадающего списка "Организация" я выбираю по строке 'Стройснаб'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И из выпадающего списка с именем "Склад" я выбираю по строке 'Оптовый неордерный склад'

        И я перехожу к следующему реквизиту

        И я перехожу к закладке "Товары"

        И в таблице "Товары" я нажимаю на кнопку с именем 'ТоварыДобавить'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 1'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И в таблице "Товары" в поле 'Количество' я ввожу текст '1,000'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И в таблице "Товары" я нажимаю кнопку выбора у реквизита "Вид цены"

        И я перехожу к следующему реквизиту

        И в таблице "Товары" в поле 'Цена' я ввожу текст '100,00'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И в таблице "Товары" я нажимаю кнопку выбора у реквизита "Ставка НДС"

        И в таблице "Товары" я завершаю редактирование строки

        И в таблице "Товары" я добавляю новую строку

        И в таблице "Товары" я активизирую поле "Номенклатура поставщика"

        И я перехожу к следующему реквизиту

        И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 2'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И в таблице "Товары" в поле 'Количество' я ввожу текст '2,000'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И в таблице "Товары" я нажимаю кнопку выбора у реквизита "Вид цены"

        И я перехожу к следующему реквизиту

        И в таблице "Товары" в поле 'Цена' я ввожу текст '200,00'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" я завершаю редактирование строки

        И я нажимаю на кнопку 'Провести и закрыть'

        И я жду закрытия окна 'Приобретение товаров и услуг (создание)' в течение 20 секунд

        И В панели разделов я выбираю 'Продажи'

        И В панели функций я выбираю 'Заказы клиентов'

        Тогда открылось окно 'Заказы клиентов'

        И в таблице "Список" я нажимаю на кнопку с именем 'СписокСоздать'

        Тогда открылось окно 'Заказ клиента (создание)'

        И из выпадающего списка с именем "Партнер" я выбираю по строке 'Алхимов А.А.'

        И я перехожу к следующему реквизиту

        И из выпадающего списка "Контрагент" я выбираю по строке 'Алхимов А.А.'

        И я перехожу к следующему реквизиту

        И из выпадающего списка "Соглашение" я выбираю по строке 'Расчеты в валюте'

        И я перехожу к следующему реквизиту

        И из выпадающего списка "Операция" я выбираю по строке 'Реализация'

        И я перехожу к следующему реквизиту

        И из выпадающего списка "Организация" я выбираю по строке 'Стройснаб'

        И я перехожу к следующему реквизиту

        И из выпадающего списка с именем "Склад" я выбираю по строке 'Оптовый неордерный склад'

        И я перехожу к следующему реквизиту

        И я перехожу к закладке "Товары"

        И в таблице "Товары" я нажимаю на кнопку с именем 'ТоварыДобавить'

        И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 1'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" в поле 'Количество' я ввожу текст '1,000'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И в таблице "Товары" из выпадающего списка "Вид цены" я выбираю точное значение '<произвольная>'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" в поле 'Цена' я ввожу текст '200,00'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" я завершаю редактирование строки

        И в таблице "Товары" я добавляю новую строку

        И в таблице "Товары" я активизирую поле "N"

        И в таблице "Товары" я активизирую поле "Номенклатура"

        И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 2'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" в поле 'Количество' я ввожу текст '2,000'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И в таблице "Товары" из выпадающего списка "Вид цены" я выбираю точное значение '<произвольная>'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" в поле 'Цена' я ввожу текст '300,00'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" я завершаю редактирование строки

        И в таблице "Товары" я нажимаю на кнопку с именем 'ТоварыДобавить'

        И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Услуга 1'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" в поле 'Количество' я ввожу текст '1,000'

        И я перехожу к следующему реквизиту

        И я перехожу к следующему реквизиту

        И в таблице "Товары" из выпадающего списка "Вид цены" я выбираю точное значение '<произвольная>'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" в поле 'Цена' я ввожу текст '500,00'

        И я перехожу к следующему реквизиту

        И в таблице "Товары" я завершаю редактирование строки

        И в таблице 'Товары' я выделяю все строки

        И в таблице "Товары" я нажимаю на кнопку 'Заполнить обеспечение'

        Тогда открылось окно 'Заполнение обеспечения и отгрузки'

        И я нажимаю на кнопку 'Заполнить'

        Тогда открылось окно 'Заказ клиента (создание) *'

        И я нажимаю на кнопку 'Провести'

        И я нажимаю на кнопку 'Реализация товаров и услуг'

        Тогда открылось окно 'Реализация товаров и услуг (создание)'

        И я перехожу к закладке "Товары"

        И в таблице "Товары" я перехожу к строке:

                | 'N' | 'Вид цены'       | 'Заказ клиента'                                    | 'Количество' | 'НДС'   | 'Номенклатура' | 'Ставка НДС' | 'Сумма'  | 'Сумма взаиморасчетов' | 'Сумма с НДС' | 'Характеристика'                   | 'Цена'   |

                | '3' | '<произвольная>' | 'Заказ клиента СБ00-000001 от 22.12.2018 19:24:17' | '1,000'      | '76,27' | 'Услуга 1'     | '18%'        | '500,00' | '500'                  | '500'         | '<характеристики не используются>' | '500,00' |

        И в таблице "Товары" я активизирую поле "Упаковка"

        И в таблице "Товары" я перехожу к строке:

                | 'N' | 'Вид цены'       | 'Заказ клиента'                                    | 'Количество' | 'НДС'   | 'Номенклатура'       | 'Склад'                    | 'Ставка НДС' | 'Сумма'  | 'Сумма взаиморасчетов' | 'Сумма с НДС' | 'Упаковка' | 'Характеристика'                   | 'Цена'   |

                | '2' | '<произвольная>' | 'Заказ клиента СБ00-000001 от 22.12.2018 19:24:17' | '2,000'      | '91,53' | 'Заказанный товар 2' | 'Оптовый неордерный склад' | '18%'        | '600,00' | '600'                  | '600'         | 'кг'       | '<характеристики не используются>' | '300,00' |

        И в таблице "Товары" я перехожу к строке:

                | 'N' | 'Вид цены'       | 'Заказ клиента'                                    | 'Количество' | 'НДС'   | 'Номенклатура'       | 'Склад'                    | 'Ставка НДС' | 'Сумма'  | 'Сумма взаиморасчетов' | 'Сумма с НДС' | 'Упаковка' | 'Характеристика'                   | 'Цена'   |

                | '1' | '<произвольная>' | 'Заказ клиента СБ00-000001 от 22.12.2018 19:24:17' | '1,000'      | '30,51' | 'Заказанный товар 1' | 'Оптовый неордерный склад' | '18%'        | '200,00' | '200'                  | '200'         | 'кг'       | '<характеристики не используются>' | '200,00' |

        И я нажимаю на кнопку 'Провести и закрыть'

        И я жду закрытия окна 'Реализация товаров и услуг (создание)' в течение 20 секунд

Почистим наш сценарий убрав шаги-дубли и лишние шаги. Опишем корректно функционал и пользовательскую историю.

Мы удаляем большую часть таких шагов как "И я перехожу к следующему элементу". Этот шаг означает фиксацию ввода в поле формы, аналог нажатия клавиши Enter. Но в ряде случае вего необходимо оставить, иначе поле ввода останется пустым. То же самое относится к шагу "И в таблице …. я завершаю редактирование строки". Оставить эти шаги нужно при последнем редактировании реквизита на каждой вкладке и при последнем редактировании реквизита в строке табличной части :

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

А теперь еще воспользуемся тегом @tree и декомпозируем его на группы шагов :

Получим такой сценарий:

#language: ru


@tree


Функционал:  Ввод реализации товаров на основании предварительного созданного заказа клиента


Как менеджер по продажам

Я хочу иметь возможность вводить реализацию товаров на основании ранее оформленного заказа покупателя

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



Контекст:

   Дано Я запускаю сценарий открытия TestClient или подключаю уже существующий



Сценарий: Проведение реализации вводом на основании из формы заказа клиента


   В системе существуют свободные остатки по товару “Заказанный товар 1” и Заказанный товар 2”


           И В командном интерфейсе я выбираю 'Закупки' 'Документы закупки (все)'

           Тогда открылось окно 'Документы закупки (все)'

           И в таблице "СписокДокументыЗакупки" я нажимаю на кнопку с именем 'Создать_ДокументЧерезФормуВыбора'

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

           И в таблице "ДеревоПоДокументам" я перехожу к строке:

               | 'Представление'                                                                                        |

               | 'Приобретение товаров и услуг                                                                        ' |

           И в таблице "ДеревоПоДокументам" я разворачиваю текущую строку

           И в таблице "ДеревоПоДокументам" я перехожу к строке:

               | 'Представление'        |

               | 'Закупка у поставщика' |

           И в таблице "ДеревоПоДокументам" я выбираю текущую строку

           Тогда открылось окно 'Приобретение товаров и услуг (создание)'

           И из выпадающего списка "Поставщик" я выбираю по строке 'Ассоль'

           И из выпадающего списка "Контрагент" я выбираю по строке 'Ассоль'

           И из выпадающего списка "Организация" я выбираю по строке 'Стройснаб'

           И из выпадающего списка с именем "Склад" я выбираю по строке 'Оптовый неордерный склад'

           И я перехожу к следующему реквизиту

           И я перехожу к закладке "Товары"

           И в таблице "Товары" я добавляю новую строку

           И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 1'

           И в таблице "Товары" в поле 'Количество' я ввожу текст '1,000'

           И в таблице "Товары" в поле 'Цена' я ввожу текст '100,00'

           И в таблице "Товары" я завершаю редактирование строки

           И в таблице "Товары" я добавляю новую строку

           И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 2'

           И в таблице "Товары" в поле 'Количество' я ввожу текст '2,000'

           И в таблице "Товары" в поле 'Цена' я ввожу текст '200,00'

           И в таблице "Товары" я завершаю редактирование строки

           И я нажимаю на кнопку 'Провести и закрыть'

           И я жду закрытия окна 'Приобретение товаров и услуг (создание)' в течение 20 секунд


И в системе создан и открыт заказ клиента с этими товарами и услугой “Услуга 1” и заданными ценами и количеством


           И В панели разделов я выбираю 'Продажи'

           И В панели функций я выбираю 'Заказы клиентов'

           Тогда открылось окно 'Заказы клиентов'

           И в таблице "Список" я нажимаю на кнопку с именем 'СписокСоздать'

           Тогда открылось окно 'Заказ клиента (создание)'

           И из выпадающего списка с именем "Партнер" я выбираю по строке 'Алхимов А.А.'

           И из выпадающего списка "Контрагент" я выбираю по строке 'Алхимов А.А.'

           И из выпадающего списка "Соглашение" я выбираю по строке 'Расчеты в валюте'

           И из выпадающего списка "Операция" я выбираю по строке 'Реализация'

           И из выпадающего списка "Организация" я выбираю по строке 'Стройснаб'

           И из выпадающего списка с именем "Склад" я выбираю по строке 'Оптовый неордерный склад'

           И я перехожу к следующему реквизиту

           И я перехожу к закладке "Товары"

           И в таблице "Товары" я добавляю новую строку

           И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 1'

           И в таблице "Товары" в поле 'Количество' я ввожу текст '1,000'

           И в таблице "Товары" в поле 'Цена' я ввожу текст '200,00'

           И в таблице "Товары" я завершаю редактирование строки   

           И в таблице "Товары" я добавляю новую строку

           И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 2'

           И в таблице "Товары" в поле 'Количество' я ввожу текст '2,000'

           И в таблице "Товары" в поле 'Цена' я ввожу текст '300,00'

           И в таблице "Товары" я завершаю редактирование строки

           И в таблице "Товары" я добавляю новую строку

           И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Услуга 1'

           И в таблице "Товары" в поле 'Количество' я ввожу текст '1,000'

           И в таблице "Товары" в поле 'Цена' я ввожу текст '500,00'

           И в таблице "Товары" я завершаю редактирование строки

           И в таблице 'Товары' я выделяю все строки

           И в таблице "Товары" я нажимаю на кнопку 'Заполнить обеспечение'

           Тогда открылось окно 'Заполнение обеспечения и отгрузки'

           И я нажимаю на кнопку 'Заполнить'

           И я нажимаю на кнопку 'Провести'



    Я нажимаю кнопку ввода на основании выбирая из меню Реализацию товаров и услуг

           И я нажимаю на кнопку 'Реализация товаров и услуг'


    Тогда открывается форма нового документа Реализация товаров и услуг

           Тогда открылось окно 'Реализация товаров и услуг (создание)'


    И в этой форме автоматически заполнен товарный состав под данным заказа, цены и количество и склад совпадает с заказом


           И я перехожу к закладке "Товары"

           И в таблице "Товары" я перехожу к строке:

               | 'Вид цены'       | 'Количество' | 'Номенклатура' | 'Сумма'  | 'Цена'   |

               | '<произвольная>' | '1,000'      | 'Услуга 1'     | '500,00' | '500,00' |

           И в таблице "Товары" я активизирую поле "Упаковка"

           И в таблице "Товары" я перехожу к строке:

               | 'Вид цены'       | 'Количество' | 'Номенклатура'       | 'Сумма'  | 'Цена'   |

               | '<произвольная>' | '2,000'      | 'Заказанный товар 2' | '600,00' | '300,00' |

           И в таблице "Товары" я перехожу к строке:

               | 'Вид цены'       | 'Количество' | 'Номенклатура'       | 'Сумма'  | 'Цена'   |

               | '<произвольная>' | '1,000'      | 'Заказанный товар 1' | '200,00' | '200,00' |


    

    И нажимаю на кнопку Провести и закрыть

           И я нажимаю на кнопку 'Провести и закрыть'


    Тогда реализация товаров успешно проводится. Под этим понимаем закрытие окна реализации без сообщения об ошибках.

               И я жду закрытия окна 'Реализация товаров и услуг (создание)' в течение 20 секунд

В Vanessa-ADD он будет выглядеть следующим образом

Посмотрим, работает ли наш сценарий:

Отлично, ошибок не было. Сценарий готов к использованию?

На самом деле нет! Мы выполняли его под полными правами. Это некорректно. Под полными правами можно делать только генерацию необходимых данных для сценариев. То есть в нашем случае генерацию свободных остатков. Заказ клиента для удобства как и реализацию будем делать из под менеджера по продажам.

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

Для запуска под конкретными пользователями в нам придется заменить шаг

    Дано Я запускаю сценарий открытия TestClient или подключаю уже существующий

на шаг запуска системы под администратором до генерации тестовых данных и закрытия тест-клиента

        Дано Я открыл сеанс TestClient от имени "Администратор" с паролем "" или подключаю уже существующий

        И я закрываю сеанс TESTCLIENT

и на шаг перезапуска системы под пользователем с ограниченными правами после генерации тестовых данных

        Дано Я открыл сеанс TestClient от имени "Менеджер по продажам" с паролем "" или подключаю уже существующий

Эти шаги можно добавить из “библиотеки известных шагов” Ванессы и затем перенести их в наш основной редактор. Библиотеки известных надеюсь удастся посвятить отдельную публикацию. А пока что посмотрим как это делается :

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

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

По умолчанию “кнопконажималка” предложит нам шаг И я изменяю флаг 'Отгрузить (при необходимости обособленно)'

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

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

На самом деле для работы с заголовком флага нам подойдет шаг

    И     я устанавливаю флаг  'Отгрузить (при необходимости обособленно)'

Ну что же, приведем текст фича-файла в его итоговом варианте и посмотрим на его работу.

#language: ru



@tree



Функционал:  Ввод реализации товаров на основании предварительного созданного заказа клиента



Как менеджер по продажам

Я хочу иметь возможность вводить реализацию товаров на основании ранее оформленного заказа покупателя

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





Контекст:



   В системе существуют свободные остатки по товару “Заказанный товар 1” и Заказанный товар 2”



           Дано Я открыл сеанс TestClient от имени "Администратор" с паролем "" или подключаю уже существующий

         

           И В командном интерфейсе я выбираю 'Закупки' 'Документы закупки (все)'

           Тогда открылось окно 'Документы закупки (все)'

           И в таблице "СписокДокументыЗакупки" я нажимаю на кнопку с именем 'Создать_ДокументЧерезФормуВыбора'

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

           И в таблице "ДеревоПоДокументам" я перехожу к строке:

               | 'Представление'                                                                                        |

               | 'Приобретение товаров и услуг                                                                        ' |

           И в таблице "ДеревоПоДокументам" я разворачиваю текущую строку

           И в таблице "ДеревоПоДокументам" я перехожу к строке:

               | 'Представление'        |

               | 'Закупка у поставщика' |

           И в таблице "ДеревоПоДокументам" я выбираю текущую строку

           Тогда открылось окно 'Приобретение товаров и услуг (создание)'

           И из выпадающего списка "Поставщик" я выбираю по строке 'Ассоль'

           И из выпадающего списка "Контрагент" я выбираю по строке 'Ассоль'

           И из выпадающего списка "Организация" я выбираю по строке 'Стройснаб'

           И из выпадающего списка с именем "Склад" я выбираю по строке 'Оптовый неордерный склад'

           И я перехожу к следующему реквизиту

           И я перехожу к закладке "Товары"

           И в таблице "Товары" я добавляю новую строку

           И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 1'

           И в таблице "Товары" в поле 'Количество' я ввожу текст '1,000'

           И в таблице "Товары" в поле 'Цена' я ввожу текст '100,00'

           И в таблице "Товары" я завершаю редактирование строки

           И в таблице "Товары" я добавляю новую строку

           И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 2'

           И в таблице "Товары" в поле 'Количество' я ввожу текст '2,000'

           И в таблице "Товары" в поле 'Цена' я ввожу текст '200,00'

           И в таблице "Товары" я завершаю редактирование строки

           И я нажимаю на кнопку 'Провести и закрыть'

           И я жду закрытия окна 'Приобретение товаров и услуг (создание)' в течение 20 секунд



   И система запущена под пользователем “Менеджер по продажам” с соответствующими ему ограничениями



           И я закрываю сеанс TESTCLIENT

           И Я открыл сеанс TestClient от имени "Менеджер по продажам" с паролем "" или подключаю уже существующий          





   И в системе создан и открыт заказ клиента с этими товарами и услугой “Услуга 1” и заданными ценами и количеством



           И В панели разделов я выбираю 'Продажи'          

           И В панели функций я выбираю 'Заказы клиентов'

           Тогда открылось окно 'Заказы клиентов'

           И в таблице "Список" я нажимаю на кнопку с именем 'СписокСоздать'

           Тогда открылось окно 'Заказ клиента (создание)'

           И из выпадающего списка с именем "Партнер" я выбираю по строке 'Алхимов А.А.'

           И из выпадающего списка "Контрагент" я выбираю по строке 'Алхимов А.А.'

           И из выпадающего списка "Соглашение" я выбираю по строке 'Расчеты в валюте'

           И из выпадающего списка "Операция" я выбираю по строке 'Реализация'

           И из выпадающего списка "Организация" я выбираю по строке 'Стройснаб'

           И из выпадающего списка с именем "Склад" я выбираю по строке 'Оптовый неордерный склад'

           И я перехожу к следующему реквизиту

           И я перехожу к закладке "Товары"

           И в таблице "Товары" я добавляю новую строку

           И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 1'

           И в таблице "Товары" в поле 'Количество' я ввожу текст '1,000'

           И в таблице "Товары" в поле 'Цена' я ввожу текст '200,00'

           И в таблице "Товары" я завершаю редактирование строки  

           И в таблице "Товары" я добавляю новую строку

           И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Заказанный товар 2'

           И в таблице "Товары" в поле 'Количество' я ввожу текст '2,000'

           И в таблице "Товары" в поле 'Цена' я ввожу текст '300,00'

           И в таблице "Товары" я завершаю редактирование строки

           И в таблице "Товары" я добавляю новую строку

           И в таблице "Товары" из выпадающего списка "Номенклатура" я выбираю по строке 'Услуга 1'

           И в таблице "Товары" в поле 'Количество' я ввожу текст '1,000'

           И в таблице "Товары" в поле 'Цена' я ввожу текст '500,00'

           И в таблице "Товары" я завершаю редактирование строки

           И в таблице 'Товары' я выделяю все строки

           И в таблице "Товары" я нажимаю на кнопку 'Заполнить обеспечение'

           Тогда открылось окно 'Заполнение обеспечения и отгрузки'

           И я устанавливаю флаг  'Отгрузить (при необходимости обособленно)'

           И я нажимаю на кнопку 'Заполнить'

           И я нажимаю на кнопку 'Провести'



 

Сценарий: Проведение реализации вводом на основании из формы заказа клиента



 

    Я нажимаю кнопку ввода на основании выбирая из меню Реализацию товаров и услуг

           И я нажимаю на кнопку 'Реализация товаров и услуг'



    Тогда открывается форма нового документа Реализация товаров и услуг

           Тогда открылось окно 'Реализация товаров и услуг (создание)'



    И в этой форме автоматически заполнен товарный состав под данным заказа, цены и количество и склад совпадает с заказом



           И я перехожу к закладке "Товары"

           И в таблице "Товары" я перехожу к строке:

               | 'Вид цены'       | 'Количество' | 'Номенклатура' | 'Сумма'  | 'Цена'   |

               | '<произвольная>' | '1,000'      | 'Услуга 1'     | '500,00' | '500,00' |

           И в таблице "Товары" я активизирую поле "Упаковка"

           И в таблице "Товары" я перехожу к строке:

               | 'Вид цены'       | 'Количество' | 'Номенклатура'       | 'Сумма'  | 'Цена'   |

               | '<произвольная>' | '2,000'      | 'Заказанный товар 2' | '600,00' | '300,00' |

           И в таблице "Товары" я перехожу к строке:

               | 'Вид цены'       | 'Количество' | 'Номенклатура'       | 'Сумма'  | 'Цена'   |

               | '<произвольная>' | '1,000'      | 'Заказанный товар 1' | '200,00' | '200,00' |



   

    И нажимаю на кнопку Провести и закрыть

           И я нажимаю на кнопку 'Провести и закрыть'



    Тогда реализация товаров успешно проводится. Под этим понимаем закрытие окна реализации без сообщения об ошибках.

           И я жду закрытия окна 'Реализация товаров и услуг (создание)' в течение 20 секунд

Готово! Мы получили тот же самый файл, что и при BDD-подходе. В данном случае он выступает в качестве сценарного теста, а не спецификации к продукту. Мы покрыли сценарным тестом уже реализованный функционал, а не создавали новый.

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

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

Обратите внимание, что большой контекст с описанием сложного поведения не рекомендуется официальной документацией https://docs.cucumber.io/gherkin/reference/#tips-for-using-background, так как это затрудняет его понимание. Но в случае Vanessa-ADD большой контекст может быть оправдан, а его читаемость можно сохранить за счет группировки шагов.

Вместо заключения: ряд методик работы

Всё ли автоматизировать?

Нет. Мне понравился слайд с последнего Heisenbug 2018 года ( https://youtu.be/4M55s_YqKc4?t=3531 ). Да попросят меня модераторы убрать эту картинку , если она нарушает правила оригинальности контента ))

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

Это же позволит повысить ценность существующих сценариев и не давать им протухать при изменении функциональности системы.

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

Что делать с проверкой серверного поведения?

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

1) Не покрывать сценарными тестами, использовать вместо этого другие виды тестирования.

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

Как адаптировать сценарии к изменениям в интерфейсе и поведении системы?

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

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

Рассмотрим пример на основе сценария выше. Допустим при формировании поступления нам необходимо заполнять не только номенклатуру, но и номенклатуру поставщика. А в заказе указывать комментарий. Нам не обязательно для этого даже запускать сценарий. Достаточно “кнопконажималкой” записать нужное поведение на произвольных формах документов, и вставить новые шаги в исходный фича-файл. А благодаря декомпозиции шагов на группы мы сможем быстро найти участки контекста и сценария, в которые нужно поместить новые шаги :

Что делать с большим количеством сценариев?

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

- Да, спасибо, Капитан Очевидность

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

В плане организации хранения и поддержки тестов очень рекомендую прочитать вот эту публикацию : https://habr.com/post/169381. Она о юнит-тестировании но всё то же самое актуально и для сценарного тестирования.

Как генерировать тестовые данные?

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

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

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

1. Подготовка тестовой базы вручную.

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

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

Поэтому вариант хоть и удобный, но редко применимый.

2. Загружать данные из заранее подготовленного файла.

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

Этот способ несет риски того, что данные могут перестать загружаться из-за изменения структур данных. И придется заново их готовить и сериализовать. Хорошим, но тяжелым вариантом здесь может оказаться “Конвертация данных 2”, которая позволит минимально привязываться к структурам данных и быстро адаптировать правила выгрузки.

В Vanessa-ADD тоже есть специальный инструмент для сериализации данных в макет MXL и загрузки данных из него. Мне этот инструмент показался "вещью в себе". По идее он работает быстрее чем “Конвертация данных 2”. Но когда сценарные и дымовые тесты занимают 30-60 минут, то экономить 30 секунд на загрузке - сомнительная идея. Документация по этому инструменту есть, но она очень краткая https://github.com/silverbulleters/add/blob/master/doc/xdd/Генерация-данных.MD и разбираться придется в основном по исходному коду :

3. Запуск подготовительных сценариев до того как будут выполняться основные.

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

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

Пока сценарных тестов мало мне этот вариант кажется самым предпочтительным.

В следующей части подробно рассмотрим установку инструментов и пройдемся по интерфейсу Vanessa-ADD, разобрав основные его элементы и их назначение.

Vanessa ADD Automation Driven Development Behavior BDD Сценарное тестирование

+349 –

См. также

Автотесты для типовых конфигураций 1С:ЗУП КОРП 3 и ЗУП 3 (vanessa automation)

DevOps и автоматизация разработки Тестирование QA Программист Пользователь Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Зарплата и Управление Персоналом 3 и версии КОРП: 3.1.30.57.

2160 руб.

05.08.2024 1272 12 1

Автотесты для типовых конфигураций ERP 2 и КА 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.17.113.

2400 руб.

04.07.2022 8364 38 1

Автотесты для типовых БП КОРП 3.0 и БП 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Программист Пользователь Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.156.30.

1800 руб.

20.01.2022 7778 19 0

В облако на работу: Вишенка на торте. Быстродействие оборудования, нагрузочное тестирование, балансировка нагрузки в кластере серверов 1С на базе РЕД ОС 8

Облачные сервисы, хостинг Linux Тестирование QA Сервера Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

Завершающая публикация цикла "В облако на работу:.. Рецепты от Капитана", в ходе которых был собран полнофункциональный рабочий контур 1С в сети на отечественной Ред ОС. С веб-серверами, доменной авторизацией, архивированием, отказоустойчивостью и прочая, прочая... В этой статье мы определяемся с быстродействием системы, проводим нагрузочное тестирование и отпускаем ее в свободное плавание (зачеркнуто) выпускаем ее в продуктовый контур, где, конечно же, придется отлавливать ошибки, мониторить состояние и т.п.

31.10.2024 1306 capitan 0

Логирование в приложениях

Журнал регистрации Тестирование QA Программист Бесплатно (free)

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

21.10.2024 2768 leemuar 8

Старт в юнит-тестах

Тестирование QA Пользователь Платформа 1С v8.3 Розничная и сетевая торговля (FMCG) Россия Бесплатно (free)

Юнит-тесты в 1С – это круто!

04.10.2024 2712 Sakharyuk_Ilya 8

Бей мутантов – спасай код

Тестирование QA Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

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

30.08.2024 1283 Scorpion4eg 6

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

Тестирование QA Программист Платформа 1С v8.3 Бесплатно (free)

Иногда возникают ситуации, когда надо развернуть тестовую базу клиента / свою на серверах Windows или Linux. Тестовые базы могут понадобиться в разных ситуациях: у клиента ошибка, на нашей базе она не воспроизводится, реализуем новый функционал и хотелось бы протестировать на Linux и т.д. А теперь представим, что это все на потоке. Что тестовых баз 1С не одна, а 20-30. И получаем проблему, что непонятно, занята она сейчас кем-то или нет. Предлагаю вариант решения этой проблемы.

28.06.2024 1504 Diversus 12

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. Сурикат 401 09.01.19 14:55 Сейчас в теме

Отличная статья!

А вы используйте Jenkins?
Как-то анализировали в сравнении gitlab-ci и jenkins?
Почему остановились именно на jenkins?

2. Vladimir Litvinenko 2896 09.01.19 15:22 Сейчас в теме

(1) Да, в публикации как раз приведены скриншоты сборочной линии на основе Jenkins. Там, где показаны графики Allure и этапы развертывания базы, выполнения тестов и подготовки cf-файлов.

Jenkins выбрал из-за доступности информации по использованию Vanessa-ADD совместно с ним. Все примеры, которые приводятся разработчиками инструмента да и вообще в сообществе, показывают как использовать для этих целей именно Jenkins c плагином Allure. Все обучающие материалы тоже. Мне, как в первую очередь разработчику 1С, важна доступность информации и поддержка сообщества по теме CI/CD. И в случае с Jenkins она есть.

С Gitlab-CI не сравнивал. Он требует знания Linux, я хоть и изучаю Linux и стараюсь его применять для личных нужд, но пока не готов в продуктиве на работе использовать. Присматривался к Bamboo так как на двух последних проектах использовались и используются продукты Atlassian. Интеграция у этих продуктов просто фантастическая, может быть продолжу изучение.

Кстати, хороший ответ на то, почему Jenkins подходит лучше всего и так широко распространён есть в следующих видео ( указал в ссылках таймстэмпы на то, где начинаются сравнения систем сборок ) :

https://youtu.be/yg5X3TYM_9Q?t=470 - Алексей Лустин, Статические анализаторы систем 1С при внедрении менеджмента качества продуктов
https://youtu.be/7SM8GLArTDY?t=570 - Кирилл Семаев, Сравнение систем CI/CD

79. Ndochp 103 05.08.21 09:39 Сейчас в теме

(1) Гитлаб зло. У него один пайплайн на все случаи жизни (запуск по комиту, ручной, внешний, специфичный для веток). Мне уже застрелиться хочется вместо написания очередного фильтра. А лучше убить кого-нибудь, кто это придумал.
Про дженкинс ничего не скажу, не использовал.

Дополню про линукс и гитлаб: что там с установкой сервера не знаю, но если им рулят админы, то для настройки сборок линукс не нужен. Можно спокойно настроить виндовый Shell-runner в качестве исполнителя на том же сервере, где крутиться тестовый 1С сервер.

3. Steelvan 306 09.01.19 15:58 Сейчас в теме

Я по Семаеву сейчас Линукс учу :)

4. ivanov660 4577 09.01.19 16:03 Сейчас в теме

Описано детально, но слишком много текста в одной статье, на мой взгляд, сходу не осилил все прочитать( бегло пролистал.

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

II) Про адаптацию. Тесты должны быть параметрическими; должна быть поддержка импорта (библиотека сценариев); должны быть максимально независимыми от тестируемой системы и др.

III) Генерация данных оптимальна перед запуском цикла тестирования, а вот
Вариант 3 для генерации данных на мой взгляд не очень хорош:
- сценарные тесты наиболее нестабильные - свалится хотя бы из-за api от 1С и все все остальные тесты гарантированно упадут,
- долгие (особенно для большого объема данных) , у нас сейчас сценарные тесты суммарно занимают около 5 часов (каждый тест в среднем 1000 различных действий), и для подготовки для них данных тоже будет адски тяжело.

Вариант 1 согласен - дохлый номер

Вариант 2 самый оптимальный (быстрый, надежный, удобный). Только в данном случае нужно аккуратно подходить к созданию сериализуемых данных и базы сборки:
создается база с условно постоянными данными (справочники, настройки и др.)
в качестве сериализуемых данных брать документы ввода остатков, ключи и др.
для задачи сериализации можно использовать различные сторонние инструменты

5. Vladimir Litvinenko 2896 09.01.19 16:29 Сейчас в теме

(4) Хотел еще описать здесь установку инструментов: Visual Studio Code и необходимых плагинов, OneScript и Vanessa-ADD как библиотеки. Но да, объем материала не позволил это сделать в одной публикации. Придется об этом рассказать в следующий раз.

Применяя Vanessa-ADD, а до этого изучая Vanessa-Behavior, всё время чувствовал нехватку информации так, чтобы она была в одном месте. Её фрагментарность очень напрягала. Поэтому постарался сделать публикацию максимально ёмкой, чтобы полностью закрыть вопрос знакомства с направлениями применения этой библиотеки.

Здесь еще тексты сценариев много места отъедают. Но пример сценария тоже нужен был. Иначе не было бы ответа на вопрос "с чем мы столкнёмся, начав применять Vanessa-ADD и стоит ли оно вообще того". Сквозной пример вообще рассчитан на то, что его можно не только прочитать, но и проработать на демо-базе УТ 11.4 или ERP 2.4.

6. spacecraft 09.01.19 16:53 Сейчас в теме

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

Смущают только примеры.

Когда ...
Тогда ...
И ...
И ...
Тогда ...
И ...
И ...
Тогда ...

Показать

Это не верно с точки зрения структуры сценария оригинального Gherkin.
"И" обозначает продолжение предыдущего этапа сценария. В данном случае это продолжение Тогда. Что по смыслу не соответствует задуманному.
Нужно разделить пример на несколько более мелких, которые укладываются в стандартные этапы, если нужны промежуточные проверки на "Тогда". А отдельные этапы "Тогда" могут быть использованы в обширном примере в качестве "Когда".

8. Vladimir Litvinenko 2896 09.01.19 16:59 Сейчас в теме

(6) Эти шаги генерируются "кнопконажималкой" - автоматическим механизмом записи действий пользователя и подставляются из библиотечных шагов, определенных в каталоге OneScript/lib/add/features/libraries. Думаю разработчикам было бы очень сложно заменять "И" на более подходящее ключевое слово анализируя окружающие шаги. При желании это можно сделать вручную, но будет трудоёмко. Vanessa-ADD позволяет даже свои библиотеки шагов писать и применять их в случае необходимости )) Надеюсь получится дойти до этой темы тоже.

9. spacecraft 09.01.19 17:05 Сейчас в теме

(8) ждем продолжения.

7. goshasilver 09.01.19 16:53 Сейчас в теме

а нам ванесса не зашла, пользуемся тестером, но статья зачетная!

10. Dach 382 10.01.19 09:38 Сейчас в теме

Прошу прощения за ламерский вопрос - верно понимаю, что так как все три фреймворка (ваша Ванесса, Тестер и 1С Сценарное тестирование) используют для вызовов форм и кнопок навигационные ссылки, как это делается в той самой древней статье на ИТС? То есть, технология одна и та же? И поэтому, тестировать конфу на обычных формах не получится? Я пробовал Тестер, он успешно подключается к тест-клиенту и видит его, но никакие сценарии не выполняются.

12. Vladimir Litvinenko 2896 10.01.19 10:24 Сейчас в теме

(10)
Все указанные инструменты рассчитаны на работу с управляемым интерфейсом, обычные формы не поддерживаются.

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

https://xdd.silverbulleters.org/c/razrabotka/vanessa-add

И два телеграмм-канала:

https://t.me/oscript_library
https://t.me/silvernation

14. AntonSm 30 10.01.19 10:40 Сейчас в теме

(10) для обычного приложения можно использовать, например, SikuliX.
https://infostart.ru/public/723210/

Или еще вариант - OneScript - WinExt.
https://infostart.ru/public/953598/

11. hawk911 10.01.19 10:00 Сейчас в теме

более ориентированным на совместное применение с СППР и коробочными решениями от 1С

Это некорректно. Мы используем Vanessa-Automation без привязки к СППР, да вообще, без привязки к 1С как "баг"-трекинг. Откуда пошла такая байка, что Vanessa-Automation не конечный продукт?

18. Vladimir Litvinenko 2896 10.01.19 11:06 Сейчас в теме

(11) Насколько я знаю Vanessa-Automation - это также развитие Vanessa-Behavior, обладающее как минимум теми же возможностями, что и исходный проект.

Развитие не отслеживал, но в тематических телеграмм-каналах видел информацию, что сейчас есть только два инструмента, позволяющие удобно работать со сценариями - Visual Studio Code и следующая СППР.

Vanessa-ADD очевидно ориентирована на VSC, Vanessa-Runner и OneScript как на Open Source и на свободно распространяемые инструменты.

https://github.com/Microsoft/vscode
https://github.com/EvilBeaver/OneScript
https://github.com/silverbulleters/vanessa-runner

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

В то же время в документации по VA на github я наоборот не нашел информации о взаимодействии Vanessa-Automation с ранее привычными для этого инструментами.

Поэтому возможно у меня создалось неправильное впечатление. А возможно правильное.

Изменил формулировку на "ориентировано в том числе на СППР".

21. Pr-Mex 136 10.01.19 11:23 Сейчас в теме

(18)

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

И от того же автора.
Список ключевых отличий VA от ADD можно посмотреть здесь.

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

Документация в разработке. Ещё не было финального релиза СППР 2.0.

В то же время в документации по VA на github я наоборот не нашел информации о взаимодействии Vanessa-Automation с ранее привычными для этого инструментами.

Vanessa runner должен работать. Но сам я его не использую.

27. AntonSm 30 10.01.19 11:44 Сейчас в теме

(21) а что используете вместо него, напишите, пожалуйста.

29. Pr-Mex 136 10.01.19 11:46 Сейчас в теме

(27)
Считается, что он уже написан, поэтому не нужно его вручную прописывать в каждую фичу. (это написано про тег @tree)

30. AntonSm 30 10.01.19 11:48 Сейчас в теме

(29) Я имел ввиду, что вы используете вместо Vanessa runner.

32. Pr-Mex 136 10.01.19 11:53 Сейчас в теме

(30)
А, понял. Сорри. Это я про тег @tree писал.

Вместо "Vanessa runner" просто используем запуск VA через /Excecute и передаём нужный JSON.
Это видится несложной задачей.

33. Vladimir Litvinenko 2896 10.01.19 12:50 Сейчас в теме

(32) Есть ли в этом случае возможность получать сообщения о ходе выполнения тестирования в процессе тестирования, а не только по его завершению?

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

Мне кажется что нельзя просто отказаться от Vanessa-Runner в этом случае. Можно только заменить его на другой инструмент. Либо работающий на платформе 1С, либо другой внешний по отношению к ней.

Если использовать инструмент на платформе 1С то мы также лишаемся возможности встроить его в сборочные линии серверов сборок (Bamboo, Jenkins и так далее) ввиду неспособности платформы работать с stdout, а значит и с ssh. По крайней мере удобной возможности взаимодействия. То есть мы вынуждены полностью замкнуться на 1С и потерять возможность использовать единый сервер сборок для всех продуктов компании.

Если же использовать другой внешний инструмент, то в чём резон отказываться от мощных возможностей Vanessa-Runner, где одновременно есть удобные команды для работы с RAS, автоматического выбора версии платформы и куча всего ещё?

35. Pr-Mex 136 10.01.19 13:25 Сейчас в теме

(33)

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

Vanessa-Runner просто читает лог файл, который отдаёт Ванесса. Эту фичу я делал ещё для оригинальной VB. Там же есть примеры скриптов, которые делают вывод в лог.
Вот так выглядит лог сборки у VA. В нём видно статус выполнения тестов в риалтайме.

Мне кажется что нельзя просто отказаться от Vanessa-Runner в этом случае. Можно только заменить его на другой инструмент. Либо работающий на платформе 1С, либо другой внешний по отношению к ней.

Кто-то должен читать текстовый файлик, который отдаёт ванесса, и выводить его в консоль. Это, конечно, может быть и Vanessa-Runner.

Ответить

23. hawk911 10.01.19 11:31 Сейчас в теме

(18) Не много не понятно, про ориентацию. В СППР более удобна работа с фичами, в целом всё. Я использую VSC, так же oscript при работе с VA.

25. Vladimir Litvinenko 2896 10.01.19 11:39 Сейчас в теме

(23) Ох. Неужели я поторопился со сменой формулировки.... ))

PS: Это был ответ на удаленную часть комментария. Поторопился и с ответом ))

13. vlad.frost 186 10.01.19 10:30 Сейчас в теме

(0)

Каждый инструмент имеет своё назначение. Для гвоздей - молоток, для шурупов - отвертка ))

Я недавно узнал, что в моём перфораторе есть три режима: молоток, перфоратор и сверло. Оказывается, с помощью одного инструмента в разных режимах можно и дырки просверлить и гвозди забить. Гвозди, правда, специальные нужны, с дюбелями, но до чего же быстро эти гвозди можно забивать!

Восхитительно, что в Vanessa-ADD совмещено два инструмента для тестирования - можно выбрать наиболее подходящий к ситуации.

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

15. Pr-Mex 136 10.01.19 10:59 Сейчас в теме

(0)
Владимир. Хорошая обзорная статья.
Начинающим - в самый раз.
///////////
В статье есть неточности. Я их отдельными комментами оформлю.

16. Pr-Mex 136 10.01.19 11:04 Сейчас в теме

(0)

Проект также является наследником Vanessa-Behavior, более ориентированным на совместное применение с СППР и коробочными решениями от 1С.

Vanessa-Automation может использоваться как самостоятельно так и вместе с СППР. Выше уже об этом писали. Исправьте пожалуйста.

19. Vladimir Litvinenko 2896 10.01.19 11:11 Сейчас в теме

(16) Ок. Изменил формулировку на "ориентированным в том числе на совместное применение с СППР".

17. Pr-Mex 136 10.01.19 11:06 Сейчас в теме

Также можно писать сценарии не использующие клиента тестирования. Например, можно написать сценарий, который нажимает на кнопки в калькуляторе Windows.

20. Pr-Mex 136 10.01.19 11:19 Сейчас в теме

В плане работы по BDD преимущества очевидны: Gherkin является стандартом и Vanessa-ADD воплощает работу с этим стандартом для платформы 1С.

В справке всех трёх ванесс (VB, ADD, VA) написано, что используется язык Turbo gherkin а не Gherkin. Синтаксис языка был существенно расширен, по сравнению с оригиналом. Лучше об этом написать.
Прикрепил скриншот.

22. Pr-Mex 136 10.01.19 11:30 Сейчас в теме

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

Обычно финальной стадией создания сценария является добавления "проверочных" шагов. Которые нельзя "накликать". Например, сравнение отчета с эталоном. Это та самая секция "Тогда" в сценарии.

24. Pr-Mex 136 10.01.19 11:38 Сейчас в теме

(0)
У вас в отчете Allure 802 сценария. Здорово! Это вместе с дымовыми тестами? Или только сценарные тесты? Можете сказать?

31. Vladimir Litvinenko 2896 10.01.19 11:51 Сейчас в теме

(24) Это вместе с дымовыми тестами.
В том контуре, который на скришнотах сценариев пока около 20. Смысл в том, что сценарные тесты постепенно заменяют дымовые, если они затрагивают те же самые формы или выполняют те же операции с объектами.

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

34. Pr-Mex 136 10.01.19 13:20 Сейчас в теме

(31)
Да, вместе лучше конечно.
Ещё лучше делать группировки к сценариям по тегам или по иерархии каталогов.
В VA сделано на основании иерархии каталогов. Также результаты нескольких сборок объединены в один отчет.
Пример можно посмотреть здесь.

41. Vladimir Litvinenko 2896 10.01.19 16:16 Сейчас в теме

(34) Спасибо! Красиво получается. Я так пока не умею ))
Указанные ниже исправления внесу в публикацию чуть позже - надо посмотреть Ваши ссылки.

43. Pr-Mex 136 10.01.19 18:28 Сейчас в теме

(41)
Приходите на партнерскую конференцию весной. На стенд СППР.
Покажу как это работает вживую )
Также есть этот чат для обсуждения ванессы.
https://t.me/testspro1c

26. Pr-Mex 136 10.01.19 11:41 Сейчас в теме

Фича-файл начинается со служебных свойств. Ими могут быть теги - слова начинающиеся с @. Эти теги имеют смысл для программного обеспечения, работающего с фича-файлами, в том числе Vanessa-ADD.

Например тег @tree для Vanessa-ADD означает, что сценарий содержит шаги, декомпозируемые на подшаги.

В Vanessa Automation не нужно писать @tree. Он подразумевается по умолчанию.

28. Pr-Mex 136 10.01.19 11:45 Сейчас в теме

(0)
Опечатка в слове делать.

Но опять же, так желать не нужно ))

36. Pr-Mex 136 10.01.19 13:28 Сейчас в теме

(0)

Каждая строка комментария должна начинаться с символа #.

Vanessa Automation ещё поддерживает комментарии в виде двух слешей //

37. Pr-Mex 136 10.01.19 13:33 Сейчас в теме

(0)

Ключевые слова шагов без двоеточий являются полностью взаимозаменяемыми. Можно употреблять одно вместо другого. Но не нужно )) Эти слова хоть все и означают начало шага, но служат для того чтобы человеку было удобно и понятно читать сценарий. К ним относятся следующие слова :
Когда
Тогда
Дано
И
Но

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

38. Pr-Mex 136 10.01.19 13:36 Сейчас в теме

(0)

Vanessa-ADD оперирует расширением языка Gherkin и в этом расширение есть еще несколько ключевых слов для циклов и условий. Например
Если, Пока

Ключевое слово Если в языке есть, ключевого слова Пока - нет. Циклы используют другой синтаксис. Исправьте, пожалуйста.

39. glebushka 273 10.01.19 13:36 Сейчас в теме

Спасибо за статью.

Если ты помнишь наш (БИТ:ERP) подход - мы используем лайфхак: чтобы сократить затраты на подготовку макулатуры и переписывание мы стараемся соблюдать следующий порядок:
1. прототип (делает консультант), без программирования, но все формы в визуальном режиме сделаны
2. BDD-сценарий (накликивается) по подготовленным формам, а потом редактируется вручную
3. написание кода, приведение форм в приличный вид

Преимущества подхода:
1. прототип можно показать бизнес-пользователям, и они могут понять о чем речь (практика показывает, что bdd-сценарии не читают и не понимают, так же как не читали и не понимали ТЗ). А это значит, что ещё до этапа документирования и разработки мы учтем существенную часть замечаний.
2. BDD-сценарий в режиме накликивания пишется быстрее, и он максимально конкретен и валидируем, в отличие от рукописного написания, где как и ТЗ - это больше литературно-художественное произведение, где допустимы множественные толкования
3. в виде произвольного текста можно позволить себе описывать действительно сложные алгоритмы, которые невозможно нормально объяснить через интерфейс пользователя.

Собственно вопрос: ты так пробовал? Что пошло не так?

Ответить

40. Vladimir Litvinenko 2896 10.01.19 15:27 Сейчас в теме

(39) Так делать не пробовали. Успел увидеть недостатки такого подхода. Прошу воспринимать только как личное мнение, могу ошибаться :

1) Консультант, создающий сценарий, не понимает всех возможностей управляемого интерфейса, высоки риски того, что UI/UX будет кривой. Исправлять консультанта после этого - это удваивать работу по разработке сценария и создавать излишнюю напряженность в отношениях, так как консультант изначально считает, что вынужден заниматься работой разработчика. В 1С фронтэнд и бэкэнд разработка не разделены и человек, хорошо понимающий разработку на управляемых формах уйдет в разработчики - выше зарплата и востребованность на рынке труда.

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

2) По поводу возможности показать интерфейс пользователю заранее согласен - плюс огромный. Но возможно лучше если к этому интерфейсу приложит руку разработчик?

Пользователь ведь действительно может принять даже неудачный интерфейс. Иногда просто молчит и терпит до последних этапов сдачи работ, потому что полагается на авторитет разработчика/косультанта, а потом вываливает всё, что накопилось за раз )) Это мой опыт, как было на проектах БИТ не знаю )) Надеюсь, что Ваш опыт всё таки удачный в этом отношении. Здесь может помочь ревью спринта, но пользователей еще надо вовлечь в активное участие в нём - обычно же ленятся.

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

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

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

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

4) Конечному пользователю лучше только прототипы показывать и как сценарий выполняется. Но есть же другие представители команды и продакт-оунер. Другое дело, что никто не хочет быть продакт-оунером. Либо хотят быть максимально ближе к биезнесу на уровне проджект-менеджера и не опускаться до "технических деталей", либо наоборот хотят только кодидить. А без этого какая же скрам-команда?

Вспоминается "Черная книга Скрам" Ивана Селиховкина с его словами : "вам всегда будет не хватать продакт-оунера" ))

42. Pr-Mex 136 10.01.19 18:19 Сейчас в теме

(40)

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

//Тот неловкий момент, когда тебя цитируют, а я не помню когда именно это говорил )

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

80. Ndochp 103 05.08.21 11:22 Сейчас в теме

(40)
по п.1:

но все формы в визуальном режиме сделаны

с учетом

(накликивается) по подготовленным формам

означает, что если конслуьтант что-то не понимает, то он это не нарисует, а не нарисует несовместимо. Так как формы изначально рисуются в конфигураторе.

2. Картинки на бумаге пользователь терпит, интерактивные формы в 1С ругает сразу (мой опыт)

3.

Сделали прототип - показали пользователю.

А показали разве не по сценарию? Сценарий это предварительная документация если не к прототипу, то к встрече по его демонстрации.

44. Pr-Mex 136 10.01.19 18:51 Сейчас в теме

(0)

Даже используя встроенный в Vanessa-ADD исследователь форм (информация о нём будет в следующей публикации) не всегда можно быстро узнать имя.

В Vanessa Automation я использую флаг "Искать элементы формы по имени". Его, скорее всего, нет в ADD, т.к. он появился уже после разделения проектов. Этот флаг позволяет сделать сценарии более стабильными относительно изменения заголовка элементов, т.к. генерируются шаги, которые ищут элементы формы по имени.
(см скриншот)

45. Pr-Mex 136 10.01.19 18:54 Сейчас в теме

(0)

Многие шаги вообще приходится реализовывать самостоятельно. Например в Vanessa-ADD есть шаг для удаления элемента справочника, но нет шага для удаления документа. А свои шаги реализуются через программирование.

У нас тестировщик просто просит добавить недостающий шаг. Обычно это не занимает много времени.

46. Pr-Mex 136 10.01.19 19:07 Сейчас в теме

(0)

На самом деле нет! Мы выполняли его под полными правами. Это некорректно. Под полными правами можно делать только генерацию необходимых данных для сценариев. То есть в нашем случае генерацию свободных остатков. Заказ клиента для удобства как и реализацию будем делать из под менеджера по продажам.

Возможно стоило сразу "накликивать" под менеджером по продаже. По крайней мере ту часть, которую делает менеджер. Мы ведь всё-равно собираемся проверять поведение под ним.

81. Ndochp 103 05.08.21 11:27 Сейчас в теме

(46) Когда для проверки контроля оплаты перед отгрузкой (допустим из АРМ складского работника) нужно под продажником завести заказ, потом под казначеем прогрузить платежи, еще под кем-то сформировать остаток на складе... То ты говоришь, а гори оно все синим пламенем и рисуешь сценарий под полными правами. И иногда забываешь самую важную финальную часть прогнать под работником склада.

47. Pr-Mex 136 10.01.19 19:13 Сейчас в теме

(0)

Каюсь за это решение )))))))))))))
Был момент, когда мне пришлось выбирать, создавать парные шаги для поиска элемента по имени, или решить это как-то по-другому.
Например, использовать спецсимволы для поиска по имени, например так
И я ищу элемент "!ИмяЭлемента".
Здесь спецсимвол - это восклицательный знак.
Так, по-моему, сделано в Тестере.

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

52. zeegin 117 10.01.19 20:00 Сейчас в теме

(47) Кстати идея с селекторами мне нравится.
Создал ишью https://github.com/Pr-Mex/vanessa-automation/issues/135

54. Vladimir Litvinenko 2896 10.01.19 23:52 Сейчас в теме

(47)
Кажется, что для полного понимания со стороны пользователей было бы достаточно просто таких названий :

И я ищу элемент по имени "ИмяЭлемента"
И я ищу элемент по заголовку "Заголовок элемента"

55. Pr-Mex 136 11.01.19 10:16 Сейчас в теме

(54)
Этот вариант рассматривался, но предполагалось, что большая часть элементов будет искаться по заголовку и поэтому это было принято по умолчанию.

56. Vladimir Litvinenko 2896 11.01.19 10:24 Сейчас в теме

(55)
Тогда может быть достаточно такого?

И я ищу элемент по имени "ИмяЭлемента"
И я ищу элемент "Заголовок элемента"

вместо

И я ищу элемент по имени "ИмяЭлемента"
И я ищу элемент "ИмяЭлемента"

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

57. Pr-Mex 136 11.01.19 11:30 Сейчас в теме

(56)
Вы имеете ввиду изменить описание шага?

58. Vladimir Litvinenko 2896 11.01.19 12:45 Сейчас в теме

(57) Да, раз сам шаг изменять нецелесообразно, то можно изменить описание. Пользователи на него тоже ориентируются.

Таких шагов много и ни в описании шага ни в сигнатуре не указывается, ведется работа с заголовком или с именем элемента формы, заданным в конфигураторе :

59. Pr-Mex 136 11.01.19 13:48 Сейчас в теме

(58)
Ок. Исправлю.
Завел задачу на это.
https://github.com/Pr-Mex/vanessa-automation/issues/136

68. Pr-Mex 136 01.02.19 21:52 Сейчас в теме

(58)
Решено в VA 1.2.019.

48. Pr-Mex 136 10.01.19 19:19 Сейчас в теме

(0)

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

53. zeegin 117 10.01.19 20:06 Сейчас в теме

(48) Скорее всего делается портянка в одном сценарии из-за того, что нет последовательности выполнения, как в схеме бизнес-процесса в СППР.
Можно посмотреть видео (если есть доступ к ИТС https://its.1c.ru/video/erp_train2018_d3_09_20), там Леня рассказывает о декомпозиции сценариев из портянки в отдельные блоки с последовательной передачей результатов одного процесса тестирования следующему.

82. Ndochp 103 05.08.21 11:36 Сейчас в теме

(48) Проверяем отсутствие письма о том, что у нас появился новый сотрудник, если это перевод между нашими юрлицами.

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

Действие:
Запустить отчет по формированию рассылки

Проверка:
Убедиться, что нового физлица нет в рассылке

Как у вас получаются короткие контексты я не понимаю. Проверка поведения документов приёма и увольнения естественно проходит в других сценариях и более подробно.

49. Pr-Mex 136 10.01.19 19:26 Сейчас в теме

(0)

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

50. Pr-Mex 136 10.01.19 19:29 Сейчас в теме

(0)

2. Загружать данные из заранее подготовленного файла.

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

Все виды сериализации данных с последующей загрузкой плохо подходят для типовых. Метаданные сильно меняются. Мы на ERP не пользуемся загрузкой из макетов или подобным.

51. Pr-Mex 136 10.01.19 19:32 Сейчас в теме

(0)

3. Запуск подготовительных сценариев до того как будут выполняться основные.

Тоже хороший вариант. Знаю проекты, которые так делают.

60. grumagargler 726 11.01.19 18:38 Сейчас в теме

Хорошая статья, давно не хватало практических примеров. Вы немного затронули тему разных инструментов, и возможно имело бы смысл отдельной статьей рассмотреть их не с точки зрения что хорошо, а что не очень, а в направлении какой инструмент для чего задумывался. Например Тестер, идейно создавался для разработчиков и очень хорошо уживается со сценарным тестированием от 1С (СТ). И с ванессой он разнится настолько, что оба могут жить каждый в своей зоне. Это еще важно и потому, что каждая компания, принимая решения об использовании того или иного инструмента, может и не задумываться о том, что они при этом теряют. Мне приходилось быть частым свидетелем ситуаций, когда СТ начинали с разработчиков, а потом постепенно делегировали отдельным тестировщикам, оставляя программистов в “покое”, т.е. ни с чем по части внутренних механизмов улучшения качества на базе автоматизации их тестов.

63. tsukanov 12.01.19 15:42 Сейчас в теме

(60) Более того хотелось бы видеть детальную таблицу сравнения возможностей и подходов.
Например, попробовав и Тестер и Ванессу, могу с уверенностью сказать что Тестер мне (программисту) удобнее.
В синтаксисе Ванессы я чувствую себя связанным по рукам и ногам. Структур данных нет, выражений нет, процедур нет. Хорошо хоть условия добавили. Понятно, что я могу под капотом реализовать любой шаг, но мне гораздо проще это делать напрямую без Ванессы.
Непрограммистам удобна наоборот Ванесса, и причина та же. Структур данных нет, выражений нет, процедур нет...
Палка о двух концах.
Делать кликеры и там и там можно, и выглядят они практически одинаково.
Но ведь тестирование не про кликеры...

64. Vladimir Litvinenko 2896 12.01.19 21:35 Сейчас в теме

(63) Для этого потребовалось бы иметь соответствующий опыт.

Возможно разделы "Различие между подходами: BDD или покрытие тестами" и "Преимущества сценарного тестирования с Gherkin" частично покрывают этот вопрос. Но конечно только частично.

Также ответ можно найти в документации:
https://docs.cucumber.io/bdd/overview/
https://cucumber.io/blog/2015/12/08/example-mapping-introduction

TDD/BDD is not about testing

A common misunderstanding of TDD and BDD is that they are testing techniques. They’re not. As the name suggests, TDD and BDD are about software development.

It is the process of approaching your design and forcing you to think about the desired outcome and API before you code.

Automated tests are a by-product of TDD and BDD.

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

Кстати, преимущества Тестера, точнее подхода к тестированию без языка Gherkin и элементов BDD, уже очень хорошо описаны во вводной части публикации посвященной Тестеру, ссылка на которую дана в самом начале этой публикации : https://infostart.ru/public/642946.

Я при выборе еще исхожу из перспектив применения инструментов :

• более тесная связь с OneScript, наличие курсов и вебинаров по их совместному применению
• связь с библиотеками для автоматизации деятельности разработчика и релиз-инженера
• публикации на ИТС

83. Ndochp 103 05.08.21 11:42 Сейчас в теме

(64) Пока единственное, чего мне не хватает в тестере - отчетов аллюр, junit для CI. Почему там их нет понятно - в самом тестере есть красивые отчеты по запускам. А мне это в единое окно хочется загнать.

В остальном - я не понимаю, почему тестер это не BDD Там отлично пишутся верхние сценарии в стиле
Позвать("ЕслиДействие 1", Параметры1)
Позвать("ИДействие 2", Параметры2)
Позвать("ИДействие 3", Параметры3)
Позвать("ИДействие 4", Параметры4)
Позвать("ТогдаВсеХорошо") // тут параметры можно не передавать, если прошлые действия писали доп сведения в __

А вот все не BDD (то есть юниты) я делаю в xUnit от V-ADD

61. headMade 144 12.01.19 13:20 Сейчас в теме

Как организован порядок запуска тестов, если их раскиданы по разным каталогам?

62. Vladimir Litvinenko 2896 12.01.19 14:45 Сейчас в теме

(61) Все файлы из всех каталогов загружаются и исполняются в произвольном порядке. На самом деле порядок конечно есть, в идеале порядок запуска тестов должен быть не важен и управлять им не нужно. И в приведенном примере на этапе сборочной линии "Сценарное тестирование" это действительно так. Фича-файлы и даже сценарии в них должны быть независимы друг от друга. Ведь фича-файлы соответствуют отдельным функциональным возможностям системы и отдельным User Story.

Порядок определен для таких разных этапов как :

1) Запуск подготовительных сценариев. Они генерируют тестовые данные и больше ничего, чтобы не делать слишком большим контекст основных сценариев (как в примере в этой публикации). Этот этап можно заменить на запуск внешней обработки, создающий тестовые данные программно. На самом деле я использую оба подхода, запуск обработки использую для сброса паролей пользователей и назначения необходимых ролей.

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

2) Запуск основных сценариев - проверка поведения, опирающаяся на созданные тестовые данные.

3) Дымовые тесты.

При таком подходе порядком исполнения управляет Jenkins на уровне этапов сборочной линии. Вы можете увидеть это на скриншотах в этой публикации. Можно сделать управление и на уровне простого bat/sh скрипта, если не хочется сразу Jenkins изучать. Но в любом случае это реализуется через запуск и завершение отдельных сеансов тест-менеджера и тест-клиента.

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

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

65. artbear 1563 14.01.19 12:22 Сейчас в теме

(0) Большое спасибо за отличную огромную статью.

И большущее спасибо за популяризацию тестирования.

Нас, активных, становится все больше.

Рад, что используешь и дорабатываешь Ванесса-АДД!

66. Vladimir Litvinenko 2896 14.01.19 12:42 Сейчас в теме

(65) Спасибо за оценку, это важно!

До участия в доработке мне ещё далеко.
Вообще не помешал бы отдельный мануал или вебинар не только по использованию инструментов, но и по участию в Open Source проектах для платформы 1С. Думаю многих останавливает от участия в доработках отсутствие доступной информации и примеров как это делать. Если с git в любом случае скоро всем придётся познакомиться, то механизм коллективной разработки на github для многих останется незнаком.

А как Вы верно заметили, интерес к этому растет. Было бы классно что-то такое увидеть, может быть участников разработки стало бы больше.

67. new_user 14.01.19 18:42 Сейчас в теме

(65) Артур, а зачем вы проверку выключили?

69. kirinalex 16 15.10.19 18:33 Сейчас в теме

Коллеги, кто использует модульное тестирование в ADD?
Поделитесь, насколько удобно в реальной работе, насколько зрелое решение?

70. user1357153 07.02.20 11:58 Сейчас в теме

Подскажите, пожалуйста, как можно вставлять случайные числа или текст, используя стандартные шаги типа:
И в таблице "Товары" в поле 'Цена' я ввожу текст '300,00'
Необходимо вводить разные значения при каждом запуске теста.
Спасибо.

71. swimdog 772 05.05.20 00:48 Сейчас в теме

Подскажите, можно ли в тестовом клиенте (из кода программы) понять, что он запущен в режиме /TESTCLIENT?

72. artbear 1563 08.05.20 13:35 Сейчас в теме

(71) Насколько я знаю, платформа этого не позволяет.

А вообще приложение лучше бы не понимать, что он работает в тестовом окружении.
Лучше юзать режим установки нужных настроек перед\при запуске приложения.
Например, json-файлы настройки или другой формат устанавливают нужные тест-настройки.
В БСП используется механизм расширений, которые переустанавливают адреса сервисов на тестовые.

А в Ванесса-АДД можно при запуске клиента тестирования указать спец. параметр через /C
например, это путь к json-файлу настройки или еще что-то

А потом приложение читает этот параметр\файл
- и выставляет нужные настройки.
- или определяет, что работает в режиме тестирования, если без этого все-таки никак )

73. swimdog 772 08.05.20 13:47 Сейчас в теме

(72) Мы столкнулись с техническим ограничением 1с/ванессы. Гиперссылка расположена на html поле и нажать ее Ванессой не получается. Под полными правами есть другая кнопка (дублирующая), которую можно нажать Ванессой. Но для ограниченного пользователя она не видна.
Идея была в том, чтобы сделать эту кнопку видимой при тестировании под ограниченным пользователем.
Паутов Леонид написал так: Нет, штатно нельзя. Нештатно - получить PID процесса и смотреть строку запуска, например.

74. artbear 1563 08.05.20 13:50 Сейчас в теме

(73) Вариант с изучением строки запуска интересный.
Но
- в Линуксе отдельная история со строкой запуска
- на Винде также необходимы доп.вычисления, что может затормозить обычных клиентов 1С в продуктивном режиме

подумайте над моими вариантами из (72)

75. artbear 1563 08.05.20 13:52 Сейчас в теме

(73) >Идея была в том, чтобы сделать эту кнопку видимой при тестировании под ограниченным пользователем.

мой вариант с передачей доп.параметра вполне подходит под этот кейс.

76. swimdog 772 08.05.20 21:15 Сейчас в теме

(75) Да, фактически через /с можно передать любые параметры. Буду пробовать, спасибо за идею

84. Ndochp 103 05.08.21 11:52 Сейчас в теме

(73) Кажется мейнстримным решением является выносить все нужные доп кнопки в расширение, которое подключается только в тестовом контуре. Главное логики там не держать - оставлять только однострочные вызовы того, что хочется нажать, но не получается.

77. dit-payments-list@sms-a.ru 30.12.20 23:10 Сейчас в теме

Здравствуйте, коллеги.
Установил Vanessa ADD через OneScript, запустил обработку bddRunner.epf, подключился к тестовому клиенту (конфигурация 1С:Документооборот). Затем попробовал "накликать" простую последовательность действий для тестирования создания внутреннего документа: через панель разделов перейти в список внутренних документов, создать внутренний документ, заполнить его и зарегистрировать. Последовательность действий "накликал", список действий в сценарии появился. Однако при попытке запустить этот сценарий появляется ошибка "Не нашли панель разделов". Попробовал проделать то же самое в Vanessa Automation - ошибка примерно та же. Что я делаю не так, коллеги?

Прикрепленные файлы: