0. Vladimir Litvinenko 09.01.19 12:42 Сейчас в теме

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

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. Сурикат 203 09.01.19 14:55 Сейчас в теме
Отличная статья!

А вы используйте Jenkins?
Как-то анализировали в сравнении gitlab-ci и jenkins?
Почему остановились именно на jenkins?
mevgenym; +1 Ответить
2. Vladimir Litvinenko 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
3. Steelvan 09.01.19 15:58 Сейчас в теме
Я по Семаеву сейчас Линукс учу :)
Vladimir Litvinenko; +1 Ответить
4. ivanov660 1262 09.01.19 16:03 Сейчас в теме
Описано детально, но слишком много текста в одной статье, на мой взгляд, сходу не осилил все прочитать( бегло пролистал.

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

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

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

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

Вариант 2 самый оптимальный (быстрый, надежный, удобный). Только в данном случае нужно аккуратно подходить к созданию сериализуемых данных и базы сборки:
создается база с условно постоянными данными (справочники, настройки и др.)
в качестве сериализуемых данных брать документы ввода остатков, ключи и др.
для задачи сериализации можно использовать различные сторонние инструменты
for_sale; +1 Ответить
5. Vladimir Litvinenko 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.
"И" обозначает продолжение предыдущего этапа сценария. В данном случае это продолжение Тогда. Что по смыслу не соответствует задуманному.
Нужно разделить пример на несколько более мелких, которые укладываются в стандартные этапы, если нужны промежуточные проверки на "Тогда". А отдельные этапы "Тогда" могут быть использованы в обширном примере в качестве "Когда".
1ceo_2015; +1 Ответить
8. Vladimir Litvinenko 09.01.19 16:59 Сейчас в теме
(6) Эти шаги генерируются "кнопконажималкой" - автоматическим механизмом записи действий пользователя и подставляются из библиотечных шагов, определенных в каталоге OneScript/lib/add/features/libraries. Думаю разработчикам было бы очень сложно заменять "И" на более подходящее ключевое слово анализируя окружающие шаги. При желании это можно сделать вручную, но будет трудоёмко. Vanessa-ADD позволяет даже свои библиотеки шагов писать и применять их в случае необходимости )) Надеюсь получится дойти до этой темы тоже.
9. spacecraft 09.01.19 17:05 Сейчас в теме
7. goshasilver 09.01.19 16:53 Сейчас в теме
а нам ванесса не зашла, пользуемся тестером, но статья зачетная!
10. Dach 252 10.01.19 09:38 Сейчас в теме
Прошу прощения за ламерский вопрос - верно понимаю, что так как все три фреймворка (ваша Ванесса, Тестер и 1С Сценарное тестирование) используют для вызовов форм и кнопок навигационные ссылки, как это делается в той самой древней статье на ИТС? То есть, технология одна и та же? И поэтому, тестировать конфу на обычных формах не получится? Я пробовал Тестер, он успешно подключается к тест-клиенту и видит его, но никакие сценарии не выполняются.
12. Vladimir Litvinenko 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
artbear; vlad.frost; +2 Ответить
14. AntonSm 24 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 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 117 10.01.19 11:23 Сейчас в теме
(18)
Насколько я знаю Vanessa-Automation - это также развитие Vanessa-Behavior, обладающее как минимум теми же возможностями, что и исходный проект.

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


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

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


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

Vanessa runner должен работать. Но сам я его не использую.
nvv1970; new_user; +2 1 Ответить
27. AntonSm 24 10.01.19 11:44 Сейчас в теме
(21) а что используете вместо него, напишите, пожалуйста.
29. Pr-Mex 117 10.01.19 11:46 Сейчас в теме
(27)
Считается, что он уже написан, поэтому не нужно его вручную прописывать в каждую фичу. (это написано про тег @tree)
30. AntonSm 24 10.01.19 11:48 Сейчас в теме
(29) Я имел ввиду, что вы используете вместо Vanessa runner.
32. Pr-Mex 117 10.01.19 11:53 Сейчас в теме
(30)
А, понял. Сорри. Это я про тег @tree писал.

Вместо "Vanessa runner" просто используем запуск VA через /Excecute и передаём нужный JSON.
Это видится несложной задачей.
nvv1970; new_user; +2 1 Ответить
33. Vladimir Litvinenko 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 117 10.01.19 13:25 Сейчас в теме
(33)
Есть ли в этом случае возможность получать сообщения о ходе выполнения тестирования в процессе тестирования, а не только по его завершению?

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


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

Кто-то должен читать текстовый файлик, который отдаёт ванесса, и выводить его в консоль. Это, конечно, может быть и Vanessa-Runner.
new_user; hawk911; zeegin; Vladimir Litvinenko; +4 1 Ответить
23. hawk911 10.01.19 11:31 Сейчас в теме
(18) Не много не понятно, про ориентацию. В СППР более удобна работа с фичами, в целом всё. Я использую VSC, так же oscript при работе с VA.
25. Vladimir Litvinenko 10.01.19 11:39 Сейчас в теме
(23) Ох. Неужели я поторопился со сменой формулировки.... ))

PS: Это был ответ на удаленную часть комментария. Поторопился и с ответом ))
13. vlad.frost 184 10.01.19 10:30 Сейчас в теме
(0)
Каждый инструмент имеет своё назначение. Для гвоздей - молоток, для шурупов - отвертка ))


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

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

Не упущу возможности поворчать на популяризаторов языка Gherkin. Если адаптировать к русскому, то делать это грамотно: вместо жаргонизмов "Функционал" использовать "Функциональность", а вместо "фича-файл" - "Спецификация".
15. Pr-Mex 117 10.01.19 10:59 Сейчас в теме
(0)
Владимир. Хорошая обзорная статья.
Начинающим - в самый раз.
///////////
В статье есть неточности. Я их отдельными комментами оформлю.
16. Pr-Mex 117 10.01.19 11:04 Сейчас в теме
(0)
Проект также является наследником Vanessa-Behavior, более ориентированным на совместное применение с СППР и коробочными решениями от 1С.


Vanessa-Automation может использоваться как самостоятельно так и вместе с СППР. Выше уже об этом писали. Исправьте пожалуйста.
19. Vladimir Litvinenko 10.01.19 11:11 Сейчас в теме
(16) Ок. Изменил формулировку на "ориентированным в том числе на совместное применение с СППР".
17. Pr-Mex 117 10.01.19 11:06 Сейчас в теме
Сценарий, написанный на языке Gherkin и сохраненный в feature-файле может быть открыт с помощью Vanessa-ADD в менеджере тестирования, а затем проигран в клиенте тестирования.


Также можно писать сценарии не использующие клиента тестирования. Например, можно написать сценарий, который нажимает на кнопки в калькуляторе Windows.
20. Pr-Mex 117 10.01.19 11:19 Сейчас в теме
В плане работы по BDD преимущества очевидны: Gherkin является стандартом и Vanessa-ADD воплощает работу с этим стандартом для платформы 1С.

В справке всех трёх ванесс (VB, ADD, VA) написано, что используется язык Turbo gherkin а не Gherkin. Синтаксис языка был существенно расширен, по сравнению с оригиналом. Лучше об этом написать.
Прикрепил скриншот.
22. Pr-Mex 117 10.01.19 11:30 Сейчас в теме
Однако простые сценарии могут быть буквально накликаны мышкой. После чего немного доработаны вручную, в основном чтобы убрать лишние шаги, сгенерированные автоматикой и сделать сценарий более читаемым (увидим это далее на сквозном примере).

Обычно финальной стадией создания сценария является добавления "проверочных" шагов. Которые нельзя "накликать". Например, сравнение отчета с эталоном. Это та самая секция "Тогда" в сценарии.
24. Pr-Mex 117 10.01.19 11:38 Сейчас в теме
(0)
У вас в отчете Allure 802 сценария. Здорово! Это вместе с дымовыми тестами? Или только сценарные тесты? Можете сказать?
31. Vladimir Litvinenko 10.01.19 11:51 Сейчас в теме
(24) Это вместе с дымовыми тестами.
В том контуре, который на скришнотах сценариев пока около 20. Смысл в том, что сценарные тесты постепенно заменяют дымовые, если они затрагивают те же самые формы или выполняют те же операции с объектами.

В то же время показалось некорректным разделять сценарные и дымовые тесты на разные отчеты. Это позволило бы получить более красивые графики, но гораздо важнее видеть всю отчетность совместно.
34. Pr-Mex 117 10.01.19 13:20 Сейчас в теме
(31)
Да, вместе лучше конечно.
Ещё лучше делать группировки к сценариям по тегам или по иерархии каталогов.
В VA сделано на основании иерархии каталогов. Также результаты нескольких сборок объединены в один отчет.
Пример можно посмотреть здесь.
Vladimir Litvinenko; +1 Ответить
41. Vladimir Litvinenko 10.01.19 16:16 Сейчас в теме
(34) Спасибо! Красиво получается. Я так пока не умею ))
Указанные ниже исправления внесу в публикацию чуть позже - надо посмотреть Ваши ссылки.
43. Pr-Mex 117 10.01.19 18:28 Сейчас в теме
(41)
Приходите на партнерскую конференцию весной. На стенд СППР.
Покажу как это работает вживую )
Также есть этот чат для обсуждения ванессы.
https://t.me/testspro1c
Korolev; new_user; Vladimir Litvinenko; +3 1 Ответить
26. Pr-Mex 117 10.01.19 11:41 Сейчас в теме
Фича-файл начинается со служебных свойств. Ими могут быть теги - слова начинающиеся с @. Эти теги имеют смысл для программного обеспечения, работающего с фича-файлами, в том числе Vanessa-ADD.

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


В Vanessa Automation не нужно писать @tree. Он подразумевается по умолчанию.
28. Pr-Mex 117 10.01.19 11:45 Сейчас в теме
(0)
Опечатка в слове делать.
Но опять же, так желать не нужно ))
Vladimir Litvinenko; +1 Ответить
36. Pr-Mex 117 10.01.19 13:28 Сейчас в теме
(0)
Каждая строка комментария должна начинаться с символа #.

Vanessa Automation ещё поддерживает комментарии в виде двух слешей //
37. Pr-Mex 117 10.01.19 13:33 Сейчас в теме
(0)
Ключевые слова шагов без двоеточий являются полностью взаимозаменяемыми. Можно употреблять одно вместо другого. Но не нужно )) Эти слова хоть все и означают начало шага, но служат для того чтобы человеку было удобно и понятно читать сценарий. К ним относятся следующие слова :
Когда
Тогда
Дано
И
Но

Полный список ключевых слов можно посмотреть здесь.
Там чуть больше. Исправьте, пожалуйста.
38. Pr-Mex 117 10.01.19 13:36 Сейчас в теме
(0)
Vanessa-ADD оперирует расширением языка Gherkin и в этом расширение есть еще несколько ключевых слов для циклов и условий. Например
Если, Пока


Ключевое слово Если в языке есть, ключевого слова Пока - нет. Циклы используют другой синтаксис. Исправьте, пожалуйста.
39. glebushka 216 10.01.19 13:36 Сейчас в теме
Спасибо за статью.

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

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

Собственно вопрос: ты так пробовал? Что пошло не так?
Krio2; 1ceo_2015; artbear; +3 Ответить
40. Vladimir Litvinenko 10.01.19 15:27 Сейчас в теме
(39) Так делать не пробовали. Успел увидеть недостатки такого подхода. Прошу воспринимать только как личное мнение, могу ошибаться :

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

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


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

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


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

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

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


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


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

Вспоминается "Черная книга Скрам" Ивана Селиховкина с его словами : "вам всегда будет не хватать продакт-оунера" ))
42. Pr-Mex 117 10.01.19 18:19 Сейчас в теме
(40)
Помню один из докладов Леонида Паутова, где он говорил что сценарий пишет разработчик. В плане конечных исполняемых шагов согласен с этим. Вот если экономим на дорогом времени разработчика, то да выгоднее переложить это на QA или консультантов. Возможно это и оправдано во многих случаях.

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

При BDD подходе, конечно, разработчик тоже пишет сценарий.
Если задача покрыть тестами то, что уже написано - тестировщик с этим замечательно справится.
44. Pr-Mex 117 10.01.19 18:51 Сейчас в теме
(0)
Даже используя встроенный в Vanessa-ADD исследователь форм (информация о нём будет в следующей публикации) не всегда можно быстро узнать имя.

В Vanessa Automation я использую флаг "Искать элементы формы по имени". Его, скорее всего, нет в ADD, т.к. он появился уже после разделения проектов. Этот флаг позволяет сделать сценарии более стабильными относительно изменения заголовка элементов, т.к. генерируются шаги, которые ищут элементы формы по имени.
(см скриншот)
45. Pr-Mex 117 10.01.19 18:54 Сейчас в теме
(0)
Многие шаги вообще приходится реализовывать самостоятельно. Например в Vanessa-ADD есть шаг для удаления элемента справочника, но нет шага для удаления документа. А свои шаги реализуются через программирование.

У нас тестировщик просто просит добавить недостающий шаг. Обычно это не занимает много времени.
46. Pr-Mex 117 10.01.19 19:07 Сейчас в теме
(0)
На самом деле нет! Мы выполняли его под полными правами. Это некорректно. Под полными правами можно делать только генерацию необходимых данных для сценариев. То есть в нашем случае генерацию свободных остатков. Заказ клиента для удобства как и реализацию будем делать из под менеджера по продажам.

Возможно стоило сразу "накликивать" под менеджером по продаже. По крайней мере ту часть, которую делает менеджер. Мы ведь всё-равно собираемся проверять поведение под ним.
47. Pr-Mex 117 10.01.19 19:13 Сейчас в теме
(0)
Здесь разработчики Ванессы постарались нас запутать. Когда встречаются подобные "парные шаги", один из этих шагов работает не с именем элемента формы, а с заголовком, а другой с именем, как оно задано в конфигураторе. "Тыжпрограммист, догадайся об этом сам". Не поступайте также когда создаете интерфейсы для своих пользователей )) Но мы же договаривались не включать негативные эмоции, когда сталкиваемся с этим в Open Source проекте ))

Каюсь за это решение )))))))))))))
Был момент, когда мне пришлось выбирать, создавать парные шаги для поиска элемента по имени, или решить это как-то по-другому.
Например, использовать спецсимволы для поиска по имени, например так
И я ищу элемент "!ИмяЭлемента".
Здесь спецсимвол - это восклицательный знак.
Так, по-моему, сделано в Тестере.

Но тогда казалось важным минимизировать доработки оригинального Gherkin, и я пошел по пути парных шагов.
Возможно стоит поддержать оба варианта.
Как считаете?
tsukanov; zeegin; +2 Ответить
52. zeegin 42 10.01.19 20:00 Сейчас в теме
(47) Кстати идея с селекторами мне нравится.
Создал ишью https://github.com/Pr-Mex/vanessa-automation/issues/135
54. Vladimir Litvinenko 10.01.19 23:52 Сейчас в теме
(47)
Кажется, что для полного понимания со стороны пользователей было бы достаточно просто таких названий :
И я ищу элемент по имени "ИмяЭлемента"
И я ищу элемент по заголовку "Заголовок элемента"
55. Pr-Mex 117 11.01.19 10:16 Сейчас в теме
(54)
Этот вариант рассматривался, но предполагалось, что большая часть элементов будет искаться по заголовку и поэтому это было принято по умолчанию.
56. Vladimir Litvinenko 11.01.19 10:24 Сейчас в теме
(55)
Тогда может быть достаточно такого?

И я ищу элемент по имени "ИмяЭлемента"
И я ищу элемент "Заголовок элемента"


вместо

И я ищу элемент по имени "ИмяЭлемента"
И я ищу элемент "ИмяЭлемента"


На самом деле это мелочь и к этому быстро привыкаешь. Но если мы хотим сделать инструменты для сценарного тестирования более распространенными , то здесь важна скорость знакомства новичков с ними, а для этого нужно уменьшить количество WTF на этапе начала работы с инструментами. А мелочей много ))
57. Pr-Mex 117 11.01.19 11:30 Сейчас в теме
(56)
Вы имеете ввиду изменить описание шага?
58. Vladimir Litvinenko 11.01.19 12:45 Сейчас в теме
(57) Да, раз сам шаг изменять нецелесообразно, то можно изменить описание. Пользователи на него тоже ориентируются.

Таких шагов много и ни в описании шага ни в сигнатуре не указывается, ведется работа с заголовком или с именем элемента формы, заданным в конфигураторе :

59. Pr-Mex 117 11.01.19 13:48 Сейчас в теме
(58)
Ок. Исправлю.
Завел задачу на это.
https://github.com/Pr-Mex/vanessa-automation/issues/136
Vladimir Litvinenko; +1 Ответить
68. Pr-Mex 117 01.02.19 21:52 Сейчас в теме
48. Pr-Mex 117 10.01.19 19:19 Сейчас в теме
(0)
Обратите внимание, что большой контекст с описанием сложного поведения не рекомендуется официальной документацией https://docs.cucumber.io/gherkin/reference/#tips-for-using-background, так как это затрудняет его понимание. Но в случае Vanessa-ADD большой контекст может быть оправдан, а его читаемость можно сохранить за счет группировки шагов.

Расскажите, пожалуйста, подробнее, зачем делать секцию "Контекст" - большой. Из статьи я не понял, почему шаги, которые "накликивают" некоторые документы находятся в контексте, а не в теле сценария. Они ведь тоже занимаются проверкой поведения. Да и секция конектста полезна, когда у нас сценариев больше одного.
53. zeegin 42 10.01.19 20:06 Сейчас в теме
(48) Скорее всего делается портянка в одном сценарии из-за того, что нет последовательности выполнения, как в схеме бизнес-процесса в СППР.
Можно посмотреть видео (если есть доступ к ИТС https://its.1c.ru/video/erp_train2018_d3_09_20), там Леня рассказывает о декомпозиции сценариев из портянки в отдельные блоки с последовательной передачей результатов одного процесса тестирования следующему.
49. Pr-Mex 117 10.01.19 19:26 Сейчас в теме
(0)
Этот вариант исключает регулярное обновление базы для запуска сценарных тестов из бэкапа рабочей базы. А значит не подходит для многих компаний, где программисты пишут код, сильно связанный с данными и где данные управляют кодом, а не наоборот.

Писать тесты на копии рабочей базы - это слишком сурово )
Лучше подготовить эталонный DT, с минимальным набором необходимых данных.
50. Pr-Mex 117 10.01.19 19:29 Сейчас в теме
(0)
2. Загружать данные из заранее подготовленного файла.

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

Все виды сериализации данных с последующей загрузкой плохо подходят для типовых. Метаданные сильно меняются. Мы на ERP не пользуемся загрузкой из макетов или подобным.
51. Pr-Mex 117 10.01.19 19:32 Сейчас в теме
(0)
3. Запуск подготовительных сценариев до того как будут выполняться основные.

Тоже хороший вариант. Знаю проекты, которые так делают.
60. grumagargler 519 11.01.19 18:38 Сейчас в теме
Хорошая статья, давно не хватало практических примеров. Вы немного затронули тему разных инструментов, и возможно имело бы смысл отдельной статьей рассмотреть их не с точки зрения что хорошо, а что не очень, а в направлении какой инструмент для чего задумывался. Например Тестер, идейно создавался для разработчиков и очень хорошо уживается со сценарным тестированием от 1С (СТ). И с ванессой он разнится настолько, что оба могут жить каждый в своей зоне. Это еще важно и потому, что каждая компания, принимая решения об использовании того или иного инструмента, может и не задумываться о том, что они при этом теряют. Мне приходилось быть частым свидетелем ситуаций, когда СТ начинали с разработчиков, а потом постепенно делегировали отдельным тестировщикам, оставляя программистов в “покое”, т.е. ни с чем по части внутренних механизмов улучшения качества на базе автоматизации их тестов.
tsukanov; Vladimir Litvinenko; +2 Ответить
63. tsukanov 69 12.01.19 15:42 Сейчас в теме
(60) Более того хотелось бы видеть детальную таблицу сравнения возможностей и подходов.
Например, попробовав и Тестер и Ванессу, могу с уверенностью сказать что Тестер мне (программисту) удобнее.
В синтаксисе Ванессы я чувствую себя связанным по рукам и ногам. Структур данных нет, выражений нет, процедур нет. Хорошо хоть условия добавили. Понятно, что я могу под капотом реализовать любой шаг, но мне гораздо проще это делать напрямую без Ванессы.
Непрограммистам удобна наоборот Ванесса, и причина та же. Структур данных нет, выражений нет, процедур нет...
Палка о двух концах.
Делать кликеры и там и там можно, и выглядят они практически одинаково.
Но ведь тестирование не про кликеры...
grumagargler; +1 Ответить
64. Vladimir Litvinenko 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, наличие курсов и вебинаров по их совместному применению
• связь с библиотеками для автоматизации деятельности разработчика и релиз-инженера
• публикации на ИТС
61. headMade 141 12.01.19 13:20 Сейчас в теме
Как организован порядок запуска тестов, если их раскиданы по разным каталогам?
62. Vladimir Litvinenko 12.01.19 14:45 Сейчас в теме
(61) Все файлы из всех каталогов загружаются и исполняются в произвольном порядке. На самом деле порядок конечно есть, в идеале порядок запуска тестов должен быть не важен и управлять им не нужно. И в приведенном примере на этапе сборочной линии "Сценарное тестирование" это действительно так. Фича-файлы и даже сценарии в них должны быть независимы друг от друга. Ведь фича-файлы соответствуют отдельным функциональным возможностям системы и отдельным User Story.

Порядок определен для таких разных этапов как :

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

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

2) Запуск основных сценариев - проверка поведения, опирающаяся на созданные тестовые данные.

3) Дымовые тесты.

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

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

Выше уже писали что в будущей версии СППР возможен другой вариант, но это уже другой идеологический подход. Если больше нравится подход с низкой связанностью и декомпозицией, то лучше выбирать независимость сценариев. Если низкая связанность не кажется ценностью, то можно выбрать вариант с зависимостью сценариев друг от друга. Возможно причина в том, что у меня сейчас мало сценариев, но сейчас мне больше нравится идея с низкой связанностью.
65. artbear 1127 14.01.19 12:22 Сейчас в теме
(0) Большое спасибо за отличную огромную статью.

И большущее спасибо за популяризацию тестирования.

Нас, активных, становится все больше.

Рад, что используешь и дорабатываешь Ванесса-АДД!
vlad.frost; Vladimir Litvinenko; +2 Ответить
66. Vladimir Litvinenko 14.01.19 12:42 Сейчас в теме
(65) Спасибо за оценку, это важно!

До участия в доработке мне ещё далеко.
Вообще не помешал бы отдельный мануал или вебинар не только по использованию инструментов, но и по участию в Open Source проектах для платформы 1С. Думаю многих останавливает от участия в доработках отсутствие доступной информации и примеров как это делать. Если с git в любом случае скоро всем придётся познакомиться, то механизм коллективной разработки на github для многих останется незнаком.

А как Вы верно заметили, интерес к этому растет. Было бы классно что-то такое увидеть, может быть участников разработки стало бы больше.
67. new_user 169 14.01.19 18:42 Сейчас в теме
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Работа от Инфостарт
Санкт-Петербург
По совместительству

Программист 1С
Хабаровск
зарплата от 90 000 руб.
Полный день

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Программист 1С
Ижевск
зарплата от 70 000 руб. до 94 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата до 120 000 руб.
Полный день