Разработка и сценарное тестирование с Vanessa-ADD. Установка инструментов. Запись действий пользователя и выполнение сценариев

В комментариях к предыдущей публикации Леонид Паутов предоставил информацию о параллельном для Vanessa-ADD проекте https://github.com/Pr-Mex/vanessa-automation. Большая часть информации, приводимая в этих публикациях, будет справедлива в отношении всех инструментов, основанных на Vanessa-Behavior, но конечно есть и отличия. У меня пока нет возможности рассмотреть особенности параллельного проекта, так как сейчас сосредоточен на использовании и описании возможностей Vanessa-ADD, но возможно вы захотите ознакомиться с ним самостоятельно.

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

Vanessa-ADD поощряет выход специалистов за рамки замкнутой экосистемы 1С. Для комфортной работы с этим фреймворком необходимы другие библиотеки OneScript и многофункциональный редактор Visual Studio Code от Microsoft. Для получения отчетности по результатам выполнения сценариев понадобится также фреймворк Allure 2 от компании Яндекс и один из вспомогательных инструментов для создания скриншотов в момент возникновения ошибок. Если же вы решите идти дальше в направлении совместной работы над сценариями и автоматизации их запуска, то потребуется также git и сервер сборок (Jenkins / TeamCity / Bamboo / Gitlab CI).

По началу это может показаться сложным, но изучив даже малую часть возможностей этих инструментов вы уже не захотите от них отказываться )) Например упомянутая в предыдущей публикации библиотека Vanessa-Runner не только упрощает автоматический запуск тестирования, но и содержит очень удобные возможности управления кластером серверов через службу RAS, как через программный код на OneScript, так и через простые консольные команды. С этой библиотекой упрощается вывод информации о ходе выполнения тестирования в консоль (stdout), а значит и в логи серверов сборок. Для запуска платформы 1С нужной версии из консоли или скрипта OneScript достаточно указать маску версии, путь будет к исполняемым файлам будет определен автоматически подобно тому, как это делает стандартный 1cestart. И это только часть возможностей.

Также важно, что все указанные инструменты являются проектами с открытым исходным кодом и распространяются свободно :

https://github.com/Microsoft/vscode

https://github.com/jenkinsci/jenkins

https://github.com/EvilBeaver/OneScript

https://github.com/silverbulleters/vanessa-runner

https://github.com/allure-framework/allure2

Сейчас ограничимся установкой OneScript , Visual Studio Code и собственно Vanessa-ADD. Именно этого набора будет достаточно, чтобы создавать, редактировать и запускать на выполнение сценарии. Установку других инструментов рассмотрим, когда перейдем к вопросу автоматического запуска сценариев. И возможно к теме отчетности, если получится добраться и до этой темы (если не получится, то посмотрите вебинары, где показаны эти возможности : Обзор возможностей Open Source продукта Vanessa-Behavior и Vanessa-ADD - Продукт для проверки качества поведения системы).

Установка инструментов

OneScript и Vanessa-ADD

Vanessa-ADD может устанавливаться отдельно от OneScript из репозитория проекта https://github.com/silverbulleters/add/releases как zip-архив. Однако гораздо более удобной и правильной установкой будет работа посредством OneScript и его менеджера пакетов opm. В этом случае мы будем устанавливать Vanessa-ADD как одну из библиотек OneScript.

OneScript можно скачать по ссылке http://oscript.io/downloads

Для Windows нам необходим первый из файлов - на текущий момент это OneScript-1.0.21-setup.exe. Архив OneScript-1.0.21.zip имеет смысл использовать если у вас на компьютере нет прав на установку программ. Этот zip-архив позволит выполнить портативную установку OneScript в домашний каталог пользователя. oscript-debug-0.3.0.vsix - это расширение для Visual Studio Code для отладки скриптов. Его удобнее устанавливать непосредственно из VSC а не отдельным файлом. Кроме того для работы со сценариями Gherkin он не требуется.

Установив OneScript из файла OneScript-x.x.xx-setup.exe в комплекте с ним мы получим только базовые библиотеки. Управлять установленными библиотеками и устанавливать новые можно с помощью менеджера пакетов opm. Если вы знакомы с концепцией управления пакетов в Linux или c Chocolatey в Windows, то подход к использованию opm покажется знакомым.

После установки, путь к каталогу с исполняемыми файлам OneScript, содержащему файлы opm.bat и oscript.exe, добавляется в переменную окружения PATH. Если этого не произошло, то нужно сделать это самостоятельно. В Windows это каталог C:\Program Files (x86)\OneScript\bin.

Благодаря этому команды opm и oscript можно будет выполнять из консоли не прописывая полный путь. Например можно выполнить команду opm list, получив полный список установленных пакетов:

Vanessa-ADD в репозитории OneScript числится под названием add и для ее установки можно выполнив команду opm install add. Также можно установить все известные менеджеру пакетов библиотеки командой opm install --all. В их числе будет и Vanessa-ADD.

При установке библиотеки также автоматически устанавливаются все библиотеки, от которых зависит указанная в команде install:

После установки в каталоге библиотек у нас появится новый подкаталог ADD.

Запускать Vanessa-ADD для работы с фича-файлами и сценариями следует в пользовательском режиме 1С:Предприятия путем открытия внешней обработки bddRunner.epf. Но запускать 1С:Предприятие при этом необходимо в режиме менеджера тестирования. Потому что Vanessa-ADD - это фактически надстройка над менеджером тестирования, которая должна запускать клиент тестирования для того чтобы проиграть сценарий или записать его.

Для этого в настройках информационной базы следуют указать ключ /TESTMANAGER.

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

Проверим установку открыв файл bddRunner.epf и выполнив запись действий пользователя :

Visual Studio Code

Для просмотра и редактирования сценариев на языке Gherkin мы будем использовать редактор от Microsoft - Visual Studio Code. Его дистрибутив можно скачать на сайте проекта https://code.visualstudio.com.

Ранее наряду с Vanessa-Behavior для создания сценаривев поставлялся инструмент bdd-editor https://github.com/silverbulleters/vanessa-bdd-editor , но в данный момент он является устаревшим.

В свою очередь VS Code является современным, расширяемым плагинами и широко распространенным редактором. Сейчас именно он предлагает наиболее удобные возможности для работы со сценариями. Есть вероятность, что другим инструментом для написания сценарных тестов может стать СППР. Но сейчас для Vanessa-ADD рекомендуемым редактором является VS Code.

Будьте осторожны! Не привыкайте к VSC. Освоив его возможности (поиск по регулярным выражениям, быстрая навигация мышью, плагины, интеграция с git, фон от которого не устают глаза), конфигуратор может показаться деревянным и вызывать боль при использовании ))

Установка VS Code возможна как в домашний каталог пользователя, так и для всех пользователей системы. Функциональность будет одинаковой. Что действительно важно - при установке не снимать флаг интеграции в меню проводника в контекстное меню каталога. Это сэкономит много нервов и движений мышью в будущем, так как и при работе со сценариями и при работе с git-репозиториями и при работе с OneScript чаще всего приходится работать с каталогом целиком :

Открыв какой либо фича-файл в VSC сразу после установки можно увидеть неприглядную картину:

Дело в том, что сразу после установки VSC поддерживает подсветку синтаксиса далеко не всех возможных языков программирования, и уж тем более языков написания спецификаций. Для работы с языком Gherkin необходимо установить одно из подходящий расширений. В меню расширений можно перейти нажав Ctrl + Shift + X или выбрав меню View → Extensions.

Произведем поиск в расширениях по ключевому слову Gherkin. В самом верху отобразятся наиболее популярные расширения связанные с этим ключевым словом. Для подсветки синтаксиса нам подойдет либо Cucumber (Gherkin) Full Support либо Snippets and Syntax Highlighting for Gherkin (Cucumber). Раньше возможности этих расширений различались, но теперь они равнозначны и подойдет любое из них:

Выбрав расширение из списка для его установки необходимо нажать маленькую кнопку Install под его заголовком, а затем кнопку Reload, появившуюся на ее месте. Это приведет к перезагрузке VSC и активации установленного расширения :

В результате установки получим подсветку , которую мы уже видели в первой части публикации :

Для VSC есть еще одно нужное нам расширение - Gherkin step autocomplete. С краткой документацией по нему можно ознакомиться по ссылке https://github.com/silverbulleters/gherkin-autocomplete. Этот плагин, несмотря на его нестабильную работу, может быть полезен при при ручном редактировании сценариев и адаптации сценариев к изменениям в тестируемой системе. Поэтому дополним его документацию разбором настроек и примерами. Устанавливается он так же как и другие плагины :

После установки необходимо выполнить настройки. Для этого в разделе настроек необходимо перейти в блок "Extensions" и затем к блоку с именем плагина :

Редактирование настроек приводит к появлению подкаталога .vscode в каталоге проекта с файлом settings.json в нем.

Нажимая на "Edit in settings.json" мы получаем возможность выполнить редактирование этого файла, но только тех строк, которые относятся к настройкам выбранного плагина, в нашем случае "Gherkin step autocomplete". Это удобнее чем редактировать файл settings.json напрямую.

Редактировать рекомендую настройки в блоке "Workspace settings". Это наиболее "точечные" настройки, которые переопределяют настройки по умолчанию для всего VSC и настройки для пользователя в целом.

Пути к библиотекам шагов "gherkin-autocomplete.featureLibraries" - это массив. Пути здесь можно перечислить через запятую так, как это позволяет делать синтаксис json-файла. На скриншоте ниже здесь указан только один путь "C:/Program Files (x86)/OneScript/lib/add/features/libraries".

Путь к подкаталогу шагов текущего рабочего пространства "gherkin-autocomplete.featuresPath" это абсолютный или относительный путь к файлам из которых мы хотим читать шаги Gherkin. Разумеется если мы говорим о нашем рабочем каталоге, то лучше задавать здесь относительный путь , а не абсолютный. Это упростит перемещение каталога с фича-файлами при необходимости. Во избежание путаницы и неоднозначной трактовки путей в VS Code относительные пути лучше начинать в Linux-стиле с точки со слешем ./

Также это файл настроек в формате JSON и поэтому в качестве разделителей каталогов в путях удобнее использовать прямые слэши. Такие слэши в JSON не нужно экранировать и кроме того файл настроек получается более универсальным - прямые слэши в путях уже давно понимает не только Linux но и Windows :

Разберем пример. Путь наши настройки заданы как на скриншоте выше. В подкаталоге subdirectory , указанном для плагина как каталог фич, мы создаем файл Фича-файл в подкаталоге.feature и в нем запишем шаг "И Я выполняю какой-нибудь шаг в подкаталоге"

Аналогично создадим файл Фича-файл в том же каталоге.feature в корне рабочей директории и пропишем в нем шаг "И Я выполняю какой-нибудь шаг в том же каталоге"

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

Видно что подтянулись шаги

Из текущего файла (это стандартный функционал VSC не требующий плагинов)
Из библиотеки "C:\Program Files (x86)\OneScript\lib\add\features\libraries". Это результат задания настройки "gherkin-autocomplete.featureLibraries"
Из файла , расположенного в каталоге subdirectory. Это результат задания настройки "gherkin-autocomplete.featuresPath"

Однако не были предложены шаги их файлов того же каталога, в котором находится файл "Демонстрация автозаполнения.feature".

Теперь укажем в качестве каталога фич сам корневой каталог - нашу текущую рабочую директорию:

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

Необходимые права на установку библиотек OneScript и настройка прав на запуск внешних обработок

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

Если подобная ошибка возникла и нет возможности обеспечить необходимый доступ для пользователя операционной системы то самый простой способ - это установить OneScript и нужные библиотеки на машину, где необходимые права есть. Затем перенести каталог OneScript на целевую машину и прописать путь к его подкаталогу bin в переменную окружения PATH. Другим способом является установка как OneScript так и Vanessa-ADD из zip-архивов.

Так как это очень редкий случай, то останавливаться на нём подробно не будем. Если вы с ним столкнётесь - предлагаю подробнее обсудить конкретные случаи в комментариях.

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

При автоматизации запуска сценариев и при построении CI-контура лучше делать это либо программно, либо разрешить запуск внешних обработок без предупреждения для баз, строка соединения которых подходит под заданную маску регулярного выражения. Подробно это описано на ИТС по ссылке https://its.1c.ru/db/v838doc#bookmark:dev:TI000001873

Например чтобы разрешить открытие внешних обработок для всех баз без ограничения нужно в файл conf.cfg внести строку DisableUnsafeActionProtection=.*

А как же Git?

Git будет необходим в двух случаях развития BDD и/или сценарного тестирования :

1) Построение CI-контура на основе какого-либо из серверов сборок. Сервера сборок очень дружат с VCS-системами и особенно с git. Код скриптов того же Jenkins очень удобно хранить в репозитории, редактировать в Visual Studio Code, вместо встроенного редактора Jenkins и настроить Jenkins на получение этого кода. Даже в этом случае применение git не обязательно, просто его использование совместно с Visual Studio Code делает работу удобной и менее трудозатратной.

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

Сейчас мы рассматриваем простые случаи индивидуальной работы, поэтому в установке git сейчас нет необходимости. Если у вас есть потребность разобраться с работой с фича-файлами или скриптами для CI-контура через git , то рекомендую следующие публикации, где рассматривается установка git и взаимодействие OneScript с ним. А также рассматривается подход gitflow для командной работы с текстовыми файлами :

//infostart.ru/public/903269/

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Интерфейс Vanessa-ADD : запись сценариев

Vanessa-ADD при запуске bddRunner.epf направляет нас сначала на вкладку "Запуск сценариев". Но чтобы иметь возможность запустить сценарий на исполнение его нужно сначала записать. Поэтому начнем знакомство с вкладок, позволяющих осуществить запись сценария : "Библиотеки", "Работа с UI" и "Test clients". Вкладка "Запуск сценариев" будет рассмотрена далее в этой части публикации.

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

Вкладка "Библиотеки"

Здесь определяются пути к библиотекам шагов Vanessa-ADD. По умолчанию здесь прописан путь только к стандартной библиотеке шагов. Именно благодаря наличию этой библиотеки мы можем использовать такие шаги как

   И я подключаю TestClient "ИмяКлиента" логин "Пользователь1" пароль "1" 

   Затем я сохраняю имя файла из переменной "ПолноеИмяФайла" как "ИмяФайла"

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

В списке библиотек можно использовать как абсолютные пути, так и заданные относительно каталога инструментов $instrumentsRoot. При этом путь к самому каталогу $instrumentsRoot указывается на вкладке "Сервис" и по умолчанию установлен в C:\Program Files (x86)\OneScript\lib\add. Менять его потребуется только в том случае, если вы выполняли установку OneScript и ADD в нестандартные каталоги:

Важно не забывать нажимать на кнопку "Сохранить настройки" при изменении настроек (на каждой вкладке своя кнопка для сохранения).

Помимо шаблона каталога $instrumentsRoot в Vanessa-ADD в зависимости от места применения есть возможность использовать и другие шаблоны подстановки:

$КаталогПроекта или $КаталогПроекта$ в тексте фича-файлов,
$workspaceRoot для настроек автозапуска.

Вкладка "Работа с UI"

Здесь выполняется работа по записи действий пользователя и редактированию полученного списка шагов, если это редактирование выполняется непосредственно в Vanessa-ADD, а не в Visual Studio Code.

Кнопка подключения тест-клиента

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

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

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

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

Вложенные вкладки : Сценарий поведения, Исходный XML , Код проверки поведения , Сценарий поведения код

Помимо представления записанных действий в виде шагов Gherkin Vanessa-ADD также предлагает несколько других представлений. Маловероятно, что ими придется часто пользоваться, но информация представленная на них позволяет лучше понять механизм работы Vanessa-ADD и самого взаимодействия между тест-клиентом и тест-менеджером.

Если на вкладке Сценарий поведения представлены шаги в виде кода Gherkin,

то на вкладке "Исходный XML" представлена информация, которая в том виде в котором она передается из тест-клиента в тест-менеджер. Это структурированная в виде XML запись действий пользователя, именно она является первоначальным результатом записи действий пользователя, которая уже затем преобразуется в код на встроенном языке 1С:Предприятия или шаги сценария Gherkin :

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

Очевидно, что такой код сложно показать аналитику, консультанту и интегрировать его с человеческим описанием поведения пользователя - это код только для виртуальной машины 1С и программиста:

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

Кнопка "Подготовить сценарий к выполнению"

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

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

Кнопка "Добавить известный шаг"

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

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

Мы уже рассматривали пример применения этого механизма при модификации существующего сценария здесь : //infostart.ru/public/969637

Сейчас Vanessa-ADD обладает одной неприятной особенностью. Если сценарий не загружен во вкладку "Запуск сценариев" или для загрузки указан несуществующий файл :

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

Группа команд "Форма" (получение состояния тестируемой формы)

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

Рассмотрим каждую из этих команд в отдельности.

Пункт "Запомнить состояние формы TestClient" и связанные с ним команды

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

   И     элемент формы с именем "ИмяЭлемента" стал равен 'ТекстовоеПредставлениеЗначения'

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

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

Эта команда работает вместе с двумя другими - "Забыть состояние формы TestClient" и "Получить изменения формы".

После нажатия на кнопку "Запомнить состояние формы TestClient" команда "Получить состояние всей формы" становится недоступной и вместо нее появляется команда "Получить изменения формы". И команда "Получить состояние всей формы" не вернётся в меню до тех пор, пока мы не выполним команду "Забыть состояние формы TestClient".

Вызов же команды "Получить изменения формы" будет всегда получать изменения между ранее запомненным состоянием и её текущим состоянием :

Пункт "Получить состояние текущего элемента формы" и тестирование отчетов

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

Это полезная возможность. Но она становится по настоящему незаменимой при тестировании отчетов!

Дело в том, что при тестировании отчетов невозможно вручную определить в Vanessa-ADD состояние печатной формы. Это можно сделать только с помощью этой команды.

Суть метода тестирования отчетов в следующем:

1) Мы выводим отчет и активируем табличный документ

2) Получаем состояние текущего элемента формы - табличного документа.

3) Оставляем в описании состояния только значимые для нас строки.

4) Заменяем шаг Тогда табличный документ формы с именем "ТабличныйДокумент" стал равен на шаг И табличный документ формы с именем "ТабличныйДокумент" содержит строки.

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

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

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

Пункт "Получить состояние всей формы"

Этот пункт активен только если ранее мы не запомнили состояние формы для получения только изменений (см.выше).

Работает аналогично команде "Получить состояние текущего элемента формы", но считывает состояние всех элементов формы, включая табличные части. Думаю что в иллюстрации здесь нет необходимости ))

Исследователь формы

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

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

Исследователь формы позволяет не заходя в конфигуратор узнать имена элементов формы, их заголовки, увидеть текущее дерево элементов с учетом в том числе программно созданных и измененных элементов. Более того, при установке флага "Получать активный элемент из TestClient" вслед за движением мышки на форме в тест-клиенте исследователь форм в тест-менеджере переходит в дереве элементов к активному элементу :

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

Вкладка "Test clients"

Очень интересна с технической точки зрения вкладка. На ней можно задать возможность подключения одного тест менеджера (текущего сеанса с Vanessa-ADD) к нескольким тест-клиентам. При этом тест-клиенты могут запускаться из разных баз и даже иметь совершенно разные конфигурации. Например один тест-менеджер может одновременно работать с тест-клиентами УТ 11 , БП 3 и ERP 2.

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

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

Srvr="HOST:1541";Ref="ut_autotest";

Srvr="HOST:1541";Ref="ut_autotest_reciever_";

Тогда список тест-клиентов можно задать следующим образом :

Фича-файл для проверки возможностей этой вкладки в этом случае можно написать такой :

#language: ru

Функционал: Проверка запуска двух тест-клиентов



Контекст:

        И я подключаю TestClient "Этот клиент" логин "Администратор" пароль ""

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

        И я подключаю TestClient "База-приемник" логин "Администратор" пароль ""

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



Сценарий: Узнаем в каком тест-клиенте будет открыта форма нового заказа

        И в таблице "Список" я нажимаю на кнопку 'Новый'

Выполним его. Можно заметить , что второй тест клиент запускается значительно дольше, чем первый. Также в нем дольше читаются списки документов. Это объясняется тем, что база данных другая, отличная от базы тест-менеджера и первого тест-клиента. Данные этой базы еще не закэшированы ни на клиенте ни на сервере :

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

Интерфейс Vanessa-ADD :

загрузка, воспроизведение и отладка сценариев

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

Загрузка фич

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

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

Если после закрытия Vanessa-ADD заново открыть ее, то файлы, с которыми велась работа перед закрытием, могут быть загружены автоматически. Этим поведением управляет настройка "Загрузка фичи при открытии" на вкладке "Сервис" :

Отображение связи шагов с реализующим их методами внешних обработок

Шаги сценариев исполняются в Vanessa-ADD благодаря наличию их обработчиков - экспортных методов внешних обработок.

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

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

Сталкиваясь с таким шагов в процессе исполнения Vanessa-ADD просто прекращает выполнение сценария, сообщает об этом, но не воспринимает это как ошибку :

Открытие сценариев на редактирование

Открыть фича-файл на редактирование можно командой "Редактировать файл фичи" из контекстного меню. Для редактирования необходимо, чтобы расширение .feature было ассоциировано с Visual Studio Code. В этом случае можно будет редактировать и затем перечитывать даже фича-файлы, находящиеся во временном каталоге операционной системы :

Выполнение сценариев

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

Часть команд выполнения можно отнести к функционалу отладки, который мы разберем ниже :

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

Отладка сценариев в Vanessa-ADD и методов, реализующих шаги, в конфигураторе

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

К другим приемам относится возможность установить точки останова и пошагового исполнения сценариев.

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

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

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

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

Остановившись на второй точке останова мы заходим в тест-клиент и свободно меняем данные формы. После чего продолжаем пошагово выполнять сценарий пока не наталкиваемся на шаг-утверждение "Тогда открылось окно 'Реализация товаров и услуг (создание)'" :

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

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

Для версий Vanessa-ADD до 5.1.0 и ранних версий параллельного проекта Vanessa-Auotmation применим общий прием отладки внешних обработок, подключаемых программно. Как мы видели выше, каждый шаг реализуется за счет внешней обработки и ее экспортного метода. Для исполнения шага bddRunner.epf создает и подключает объект внешней обработки средствами встроенного языка 1С, затем вызывает экспортный метод формы этой обработки.

Для отладки экспортного метода внешней обработки, подключаемой программно, необходимо запустить тест-менеджер из конфигуратора. До самого первого исполнения шага открыть реализующую его внешнюю обработку в этом сеансе тест-менеджера через "Файл → Открыть". Затем открыть эту обработку в конфигураторе, найти нужный метод в форме обработки и поставить в нём точку останова. Затем можно выполнять сценарий в bddRunner.epf - точка останова сработает.

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

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

Разумеется этот приём отладки сработает всегда. Но начиная с версии Vanessa-ADD 5.1.0 и в новых версиях параллельного проекта Vanessa-Automation отладка упрощается. Если база файловая или база серверная, но тест-менеджер и тест-клиент запускаются на том же компьютере, на котором запущен сервер 1С, то не обязательно перед началом отладки открывать внешнюю обработку через "Файл → Открыть" в тест-менеджере. Достаточно просто открыть реализующую шаг обработку в конфигураторе, поставить в ней нужную точку останова и она сработает.

Если же база клиент-серверная и тест-менеджер запускается на машине, отличной от той, на которой запущен сервер 1С, то правила остаются прежними.

В более формальном виде правила отладки приведены в документации на github: https://github.com/silverbulleters/add/blob/master/F.A.Q.MD

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

тестирование обмена в РИБ,
сценарии проверки движений документа,
прикрепление файлов,
выполнение произвольного кода 1С,
запуск нескольких тест-клиентов и т.д.

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

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

+258 –

См. также

Автотесты для типовых конфигураций 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 1278 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 8368 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 7783 19 0

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

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

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

31.10.2024 1308 capitan 0

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

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

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

21.10.2024 2781 leemuar 8

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

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

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

04.10.2024 2717 Sakharyuk_Ilya 8

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

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

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

30.08.2024 1292 Scorpion4eg 6

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

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

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

28.06.2024 1511 Diversus 12

Комментарии

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

Свернуть все

1. Vladimir Litvinenko 2896 21.01.19 00:54 Сейчас в теме

За время, прошедшее с первой публикации, появилось ещё одно новое видео по рассматриваемой теме на канале "ФТО-Проект". Рекомендую посмотреть :

https://www.youtube.com/watch?v=2Ulzs81ExB4

Ответить

10. Pr-Mex 136 21.01.19 14:50 Сейчас в теме

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

17. Vladimir Litvinenko 2896 21.01.19 15:33 Сейчас в теме

(10) Хотелось бы избежать горячих обсуждений "у кого лучше" ) Всё таки тема посвящена вопросам установки и интерфейсу. А ссылкой на доклад просто захотелось поделиться как на новое видео по рассматриваемой теме.

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

На канале ФТО есть еще несколько отличных видео с этой встречи. В том числе выступление Петра Грибанова по новым механизмам платформы 1С.

2. Meteorage 21 21.01.19 06:13 Сейчас в теме

Шикарная статья. Выражаю особую благодарность за подробное описание. У меня сейчас как раз проект в котором я хочу внедрить данные технологии.

Ответить

3. artbear 1563 21.01.19 12:34 Сейчас в теме

(0) Огромное спасибо за две обалденные и очень полные статьи :)

Ответить

4. Pr-Mex 136 21.01.19 12:56 Сейчас в теме

(0)
Спасибо за статью.
Единственное что не очень - это гифки. В них нет паузы и перемотки. Не всегда удобно смотреть.

9. oleynik.dv 164 21.01.19 14:35 Сейчас в теме

(4) Позвольте с вами не согласиться, уважаемый коллега! ;-)
Размер имеет значение. Хорошая гифка на 3-5 сек в тексте намного нагляднее статичной картинки. Тут важно чувство меры.

Вопрос к Владимиру: каким инструментом гифки делаете? (интересуюсь с целью перенять опыт)

11. Vladimir Litvinenko 2896 21.01.19 14:57 Сейчас в теме

(9) Gif-анимацию записываю через LICEcap. Он умеет делать паузу (только во время записи), но я этим не пользуюсь, так как иначе время необходимое для удачной записи сильно увеличится.

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

12. Vladimir Litvinenko 2896 21.01.19 15:01 Сейчас в теме

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

13. Pr-Mex 136 21.01.19 15:02 Сейчас в теме

(12)
Именно. Поэтому я планирую в ближайшем времени переход на автовидео инструкции.

15. Vladimir Litvinenko 2896 21.01.19 15:10 Сейчас в теме

(13) Они же перестали работать в последних версиях платформы. С 8.3.12 точно, а кажется даже с 8.3.9. Разве нет?
Мы пытались их применять в компании. Выделение активного элемента больше не работало. Удалось частично починить - коллега вносил изменения в механизм. Но кнопки командной панели так и не получилось заставить выделяться. Смотрели как в ADD, так и в Automation.

16. Pr-Mex 136 21.01.19 15:23 Сейчас в теме

(15)
Сама запись автовидео как работала так и работает.
Начиная с 8.3.12 нельзя определить координаты элемента на экране через win api, поэтому нельзя подсветить активный элемент на экране и подвести к элементу курсор мышки. Но эти проблемы я решаю в новых автовидео.

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

(16) Спасибо! Будет хорошо, если получится.

22. Pr-Mex 136 21.01.19 16:40 Сейчас в теме

(15)

Удалось частично починить - коллега вносил изменения в механизм

Можно поподробнее про эти изменения?

23. Vladimir Litvinenko 2896 21.01.19 16:45 Сейчас в теме

(22) Извиняюсь, я дезинформировал )) Сейчас узнал - "починка" заключалась в применении старой версии платформы 8.3.6 для записи видеоинструкций для нашей конфигурации )) Была попытка попробовать изменить код на Паскале, но получилось запустить конфигурацию на старой версии платформы.

24. Pr-Mex 136 21.01.19 17:12 Сейчас в теме

(23)
Понял. Спасибо.

5. artbear 1563 21.01.19 14:09 Сейчас в теме

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

(0) подобное подключение отладки устарело и нужно редко.

я еще в версии 5.1.0 Vanessa.ADD (т.е. довольно давненько) сделал более удобный механизм отладки - абсолютно штатная 1С-отладка шагов/тестов, если файл с клиента доступен на сервере.

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

Теперь не нужно мучаться с отладкой шагов, как раньше :)

14. Vladimir Litvinenko 2896 21.01.19 15:06 Сейчас в теме

(5) Хм, а может быть я именно эту возможность за нововведения в платформе 8.3.14 принял? ))
Заметил, что обработки, реализующие шаги по прежнему нужно открывать для их успешной отладки, но только если подключение отладчика произошло уже потом, после запуска тест-менеджера. Если же тест-менеджер запускается из конфигуратора, то в этом не было необходимости.

6. artbear 1563 21.01.19 14:14 Сейчас в теме

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

(0) Еще команда "Генератор макетов данных" очень полезна

А в новой версии еще одна полезная команда появляется - "Управление дымовыми тестами"

7. Shmell 546 21.01.19 14:24 Сейчас в теме

Спасибо! все объединили в одном месте. Добавил в избранное.

8. oleynik.dv 164 21.01.19 14:25 Сейчас в теме

Отличный мануал! У самого бы руки никогда не дошли.
А тут прям в таком виде можно давать новым сотрудникам. Круто.

19. artbear 1563 21.01.19 16:10 Сейчас в теме

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

(0) Могу помочь разобраться, что не так с подстановкой шагов фич через gherkin.autocomplete в VSC

Здесь или на форуме https://xdd.silverbulleters.org/c/razrabotka/vanessa-add

21. Vladimir Litvinenko 2896 21.01.19 16:27 Сейчас в теме

(19) Продублирую описание установки и описанный здесь эффект на форум, как только появится время.
Возможно проблема в том, что на машинах, где редактирую сценарии, установлена Windows 7. Как на домашнем, так и на рабочем компьютере. Где-то читал, что с Windows 7 проблемы возникают с этим плагином. На CI-сервере где Windows Server 2016 плагин не ставил. Посмотрю поведение на нём чуть позже, может быть такой эффект наблюдаться не будет.

20. artbear 1563 21.01.19 16:12 Сейчас в теме

Кстати, всем напомню, что поддержка по продукту Vanessa.ADD оказывается

1 на нашем форуме https://xdd.silverbulleters.org/c/razrabotka/vanessa-add
- (предпочтительно, т.к. история сохраняется и в разных ветках есть разные контексты)

2 и в чате-телеграме Серебряной Пули https://t.me/silvernation

3 или в чатах статей про Vanessa.ADD на ИС, таких, как эта статья.

25. tsukanov 21.01.19 19:02 Сейчас в теме

(20) Написав вопросы на форуме 12 дней назад так и не дождался ни одного комментария )
Поддержка платная или я что-то не то / не так спросил?

26. tsukanov 21.01.19 20:16 Сейчас в теме

Владимир, спасибо за статью. Но есть ряд вопросов.
Я уже давно хочу задать эти вопросы и все никак не решаюсь (чтоб никого не обидеть).
Но думаю таки стоит спросить:
Видел несколько статей, видел вебинары кусками (выделить время на полный анализ сложно). И каждый раз это большой объем информации с крайне низким КПД (по личным ощущениям).
Например, то что описано в данной статье (просмотрел по диагонали), по большей части проблемы не представляет. Почти все выясняется методом научного и не совсем тыка. Причем довольно быстро (по крайней мере мы в основной механике разобрались за день без погружения во все эти публикации). Мне кажется программисту внутренняя кухня должна быть очевидна.
Но когда ты разобрался в механике, возникает куча вопросов совершенно другого плана.
Как тестировать то? Я вижу как в вебинарах и видео говорится что нужно писать высокоуровневые шаги, а затем программист их реализует.
Но когда я вижу статьи и скриншоты с типа реальными примерами, то возникает когнитивный диссонанс, т.к. там кликеры, а совсем не то, что вроде как должно быть. Так а где примеры не кликеров? Я что-то пропустил? есть ссылки?
Дело в том, что видится два варианта использования и оба с проблемами:
1. Высокоуровневые шаги (тру) - проблема в переиспользовании.
Как это делать?
Я знаю как это делать в Тестере, например. Там переиспользование получается само собой с порога, т.к. там полноценный язык программирования. Сделал общий сценарий создания документа (реализации, например), который принимает структуру данных документа и погнал. Кликер для реализации будет сделан один раз в одном месте. Но как этого добиться с Ванессой? Если попытаться сделать то же самое, что в Тестере, то получится дикий изврат, т.к. в Ванессе нет структур данных. Да и концепция читаемости будет вырублена на корню.
Как быть то?
2. Низкоуровневые шаги (кликер) - проблема в декомпозиции.
Получаются длинные портянки, читаемость которых по ощущениям еще ниже чем у кода 1С. Мне (программисту) их читать субъективно сложнее. Типа возник у тебя вопрос: "Какая сумма вводится туда-то в том-то документе?" и начинаешь судорожно искать глазами нужную строчку в этом мусоре.
В общем длинные портянки очевидно нужно разбивать на какие-то части. Но как? Экспорт сценариев?
Человек не связанный с программированием таким скилом (декомпозиция) тупо не обладает.
И даже для программиста возникают вопросы. Например, есть 10 сценариев, которые используют общие данные, которые хотелось бы создавать кликами как юзер. Как сделать так, чтобы запустив 10 сценариев, данные были созданы только один раз?
Делать и передавать между сценариями уникальный ключ данных как в Тестере? Но это опять же повышает требования к человеку пишущему сценарии.

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

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

ps Пардон за сумбур и ужасный текст. Надеюсь мысль донес

Ответить

28. goshasilver 21.01.19 23:10 Сейчас в теме

(26) вот прям написали, что болело, мало опыта боялись спрашивать. Тоже с тестером работаем, там чтоли все больше для дела реализовано и мануал в одном месте а не нужно собирать по крупицам

29. Vladimir Litvinenko 2896 22.01.19 00:49 Сейчас в теме

(26)

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

Да, такая проблема есть, писал про неё еще во введении к первой части https://infostart.ru/public/969637. Именно это и сподвигло к выпуску публикаций. Но здесь Вы должны понимать, что эти продукты создаются на энтузиазме разработчиков. И среди 1С-ников очень мало людей, готовых помочь в разработке. Мало даже людей, которые вообще способны участвовать в совместной разработке на github по незнакомым правилам игры. Мы же дети типовых конфигураций и хранилища в формате .1CD. Чтобы задействовать git на проектах приходится уговаривать коллег "ребята это не страшно, оно не кусается". И всё равно то и дело встречаешь страх английских слов "Blame" и "Review" и нежелание совместно работать над кодом. Разработчики из других языков ржут... громко ))

На мой взгляд фирме 1С стала невыгодна такая ситуация с замкнутостью легко заменяемых разработчиков 1С на хранилище и конфигураторе по одной причине - захотелось на западный рынок. Поэтому сейчас всё на git будут переводить и на EDT. Надо изучать. Но не поздновато ли? ))

И вот в этих условиях рождаются и развиваются такие мощные проекты на github. Требовать от разработчиков при этом еще и бесплатных курсов и всеобъемлющей документации несправедливо. А вот мы со своей стороны можем помочь информационно и сделать эту самую документацию. Или хотя бы что-то похожее на неё.

Сейчас помимо этих публикаций хорошими источником информации по практическому применению является встроенная в bddRunner.epf справочная информация. Альтернатива - собирать по кусочкам из вебинаров, форумов и чатов - за неделю можно многому научиться. Помню кто-то из разработчиков написал, что сейчас вообще наблюдается тенденция к ЧДД - "чат driven documentation" ))

Ранее ещё был курс https://infostart.ru/special/bdd. Но он был изрядно устаревшим еще тогда когда его проходил - в 2017 году и сейчас требует переработки. Если откровенно, то у меня самого после него не получилось начать работать с инструментом. Слишком много дыр в голове осталось, много времени было уделено bdd-editor, который теперь в статусе depricated. Visual Studio Code тогда еще не применялся. Больше помог второй курс https://infostart.ru/public/597500, где речь про Vanessa-Beravior не ведётся, но в нём рассказано про построение CI-контура и даже с основами применения Докера познакомиться можно. Впоследствии собрал CI-контур по другому, но курс задал вектор, чтобы дальше развиваться, понимая где и какую искать информацию. Рекомендую.

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

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

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

Но когда я вижу статьи и скриншоты с типа реальными примерами, то возникает когнитивный диссонанс, т.к. там кликеры, а совсем не то, что вроде как должно быть. Так а где примеры не кликеров? Я что-то пропустил? есть ссылки?

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

Подозреваю, что такой же синдром есть у абаперов на SAP и прочих сильно зависящих от одного вендора и одного набора инструментов разработчиков. "Я же 1С-ник/Сапёр, зачем мне всё это! Уберите от меня эти страшные штуки! Я итак деньги заработаю!". И ведь зарабатывают )) Часто пользователи очень не скоро могут понять, что им в систему болячку подсунули и она систему разрушает до тех пор, пока другие "врачи в жёлтых халатах" уже не могут справиться ))

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

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

1. Высокоуровневые шаги (тру) - проблема в переиспользовании.
Как это делать?

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

Если же Вы пишете свои собственные реализации шагов (через свои внешние обработки), то может оказаться так, что Ваш шаг вообще не нуждается в разбиении на более мелкие шаги, а является самодостаточным и переиспользуемым. Например можно создать шаг
"Я перепровожу последовательность документов за текущий месяц".
Затем реализовать этот шаг в экспортном методе обработки, точно также как делал бы коллега-программист на Java. После чего этот шаг можно переиспользовать сколько душе угодно.

Другим вариантом переиспользвоания являются экспортные сценарии.

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

Низкоуровневые шаги (кликер) - проблема в декомпозиции.
Получаются длинные портянки, читаемость которых по ощущениям еще ниже чем у кода 1С. Мне (программисту) их читать субъективно сложнее. Типа возник у тебя вопрос: "Какая сумма вводится туда-то в том-то документе?" и начинаешь судорожно искать глазами нужную строчку в этом мусоре. В общем длинные портянки очевидно нужно разбивать на какие-то части. Но как? Экспорт сценариев?

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

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

Постараюсь привести примеры на этот счёт в следующий раз.

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

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

Я это делаю через специальный этап сборочной линии - "Подготовка тестовых данных". Разворачиваю тестовую базу из копии рабочей (да да из копии рабочей, потому что программисты накодили там поиск по наименованию, кое где вшиты GUID и прочий хардкод, алгоритмы зависят от кучи пользовательских данных, просто так маленькую демо базу не сделать). Затем запускаю обработку инициализации - она готовит пользователей, сбрасывает пароли. Затем стартовые сценарии - подготовка тестовых данных.

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

Вот эти вещи где-то освещены?

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

Что вообще может сделать писатель фич без программиста?

Многое. Это ещё зависит от того, кто является писателем. Если писатель - QA-инженер, то может составить тест-кейс. Автоматически записать по нему шаги "кнопконажималкой". Затем декомпозировать их на группы в соответствии с тест-кейсом. Если это аналитик - то его задача бизнес логику прописать.

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

В то же время возможности QA очень большие. Из того, что видел по другим языкам программирования, мне кажется в 1С сейчас одни из самых мощных инструментов для этого.

Как правильно взаимодействовать писателю и программисту.

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

Кто организует структуру сценариев? Писатель на уровне фич или программист под капотом?
Через год это не превратится в груду мусора (или, как модно говорить, тех. долг)?

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

Надеюсь мысль донес

Более того, почти со всеми мыслями согласен ))

Ответить

33. tsukanov 22.01.19 19:16 Сейчас в теме

(29) Спасибо за развернутый комментарий!
Так, в диалоге, многое становится в яснее.

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

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

Да, я это понимаю. Правда не все так просто, как вы описали. Одно дело когда фигачит группа энтузиастов и совсем другое дело когда речь идет о продукте конкретной конторы ) Мы ведь не дети, да? Все прекрасно понимают, что, к примеру, Microsoft пилит бесплатный открытый VSC совсем не по доброте душевной )
Дальше не буду углубляться. Думаю вопрос совместной разработки можно закрыть не открывая. И больше вообще об этом не заикаться. Каждый сам выбирает с каким логотипом на груди ходить (тут отсылка к будущему по Гибсону)

Мы же дети типовых конфигураций и хранилища в формате .1CD. Чтобы задействовать git на проектах приходится уговаривать коллег "ребята это не страшно, оно не кусается". И всё равно то и дело встречаешь страх английских слов "Blame" и "Review" и нежелание совместно работать над кодом. Разработчики из других языков ржут... громко ))

Знаете, тут не соглашусь. Над разработчиками на других языках тоже можно поржать. У нас в 1С в хранилище уж сколько лет можно допиливать (иногда сильно) вендорский продукт, и при этом силами джуниора делать слияние.
Разработчики из других языков такого в гите не имеют (ну или я чего-то не знаю). Blame не так уж и нужен на практике. Ну разве что тимлиду чтобы унижать джунов. В хорошей команде всем должно быть по барабану кто писал код, имхо. А для понимания истории обычного хранилища достаточно. Review - это нужная штука, да. Вот только с чего вы взяли что у разрабов на других языках с этим все норм? Я видел реально годное ревью только у команды Go. И при этом они используют инструмент, который сами же и написали ЕМНИП. Температура в целом по больнице мне не известна, но всегда казалось что это общая боль (вменяемый инструмент трудно найти)

У меня для любой идеи/технологии/задумки в голове всплывает стандартный вопрос: "Какую проблему это решает?"
И какую проблему решает git? Мне она не очевидна.
Вы только не подумайте что я консерватор. Сам внедрял в своей конторе SVN с разбором обработок и затем Git тогда, когда всей этой модной движухи еще не было (12/13 год). Но делалось это для решения конкретной проблемы в моей конторе - хаос с внешними обработками (типичная проблема для фикси). Т.е. я достаточно давно "в теме", но ваши взгляды не разделяю )

ps Продолжение следует... )
pps Да, тут не по теме исходных моих вопросов. Просто возник интерес и другие темы затронуть

34. Vladimir Litvinenko 2896 22.01.19 19:51 Сейчас в теме

(33)
Могу порекомендовать хорошие инструменты Crucible+Fisheye , сейчас на Github есть файлы настроек для подсветки синтаксиса языка 1С для Crucible.

Когда-то использовал в связке с Bitbucket и настраивал только выгрузку хранилища в Bitbuket для связи с задачами в Jira и ревью в Crucible. Но в начале осени настраивал все эти продукты самостоятельно и выяснил, что для посткоммитного ревью (когда в git автоматически отправляются уже помещенные в хранилище изменения) достаточно связки Crucible+Fisheye.

Стоят дорого, но можно использовать триалки.

Здесь есть мой вопрос в сообщество со ссылками на то, что ранее использовал и хотел получить от более простой связки (один из скриншотов не открывается):
https://community.atlassian.com/t5/Jira-questions/Choosing-between-Fisheye-and-Bitbucket-to-integrate-with/qaq-p/887851

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

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

Собственно про преимущества git наверное не буду много писать. Это всё очень просто ищется и в поисковиках и на Инфостарте. Как правило картинок больше, чем советов по настройке. Но я для настройки отдельную публикацию делал : https://infostart.ru/public/903269

35. tsukanov 22.01.19 20:29 Сейчас в теме

(34)

Могу порекомендовать хорошие инструменты Crucible+Fisheye , сейчас на Github есть файлы настроек для подсветки синтаксиса языка 1С для Crucible.

Спасибо за наводки )

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

Пользовался Blame начиная с SVN (это не фишка гита). Ничего оно мне на практике так и не дало )
Ну т.е. нафантазировать пользу я могу, но по факту на практике не помню чтоб нужно было.

Когда перелезем на EDT, эта фишка конечно будет приятным бонусом )

Собственно про преимущества git наверное не буду много писать. Это всё очень просто ищется и в поисковиках и на Инфостарте. Как правило картинок больше, чем советов по настройке. Но я для настройки отдельную публикацию делал : https://infostart.ru/public/903269

Спасибо, про публикации и всеобщее увлечение гитом мне известно )
Затронул эту тему только потому что интересен этот социальный феномен.

37. tsukanov 23.01.19 20:14 Сейчас в теме

(29)

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

Если конечная цель - кликер для прикладника, то в общем то все норм. Это можно понять и принять (мерещится что так все и делают в общем то)

У нас в отрасли сильная неофобия. При этом боятся разработчики 1С даже не нового, а старого. Того, что другие разработчики уже десятилетия стабильно применяют.

Вы считаете что неофобия - это плохо? Думается неофобия - это один из самых важных скилов в современном обществе. Потому что "экспертов" и "новаторов" вокруг стало слишком много. И все обещают чудеса. И все это в 99% случаев пузыри.

А про других разработчиков... Вы же знаете историю про "величайшую победу запада в холодной войне"?
Это когда наши решили копировать IBM-360.
У нас (у русских) есть национальная забава - копировать, подражать и воровать.
Так и живем на западных идеях и технологиях.
Это повод гордиться? Да вроде нет.
Мы тупые? Похоже что да. Но это опять же не повод гордиться.
Так почему же разработчики 1С должны наступать на те же грабли, на которые этот народ наступал уже сотни раз?

ps Я не считаю что вы не правы. Я просто пытаюсь показать что все несколько сложнее. Нельзя впадать в крайность - это основной посыл

60. tsukanov 26.01.19 20:51 Сейчас в теме

(29)

Да, примеры больше всего хотелось бы увидеть )

Это же как разбивать код на процедуры и функции

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

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

Понимаете? На один шаг вперед видно, на два вроде тоже, а вот дальше туман. Если бы геркин/ванесса была сделана как классический ЯП, то и вопросов бы не было.

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

61. Vladimir Litvinenko 2896 26.01.19 22:14 Сейчас в теме

(60)

Осветите, пожалуйста, подробнее эти моменты в следующей статье.

Ох, следующая статья уже готова. Получилась такая, какая получилась )) Завтра вечером отправлю на модерацию. Там будет только практика на УТ 11. Три примера, начинаются с высокоуровневых шагов, затем "накликивание" на их основе, и затем переход к полноценному сценарию через объединение исходного сценария и исполняемых шагов.

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

62. tsukanov 27.01.19 14:48 Сейчас в теме

(29)

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

Мне кажется сообществу при обсуждении нужно четко разграничивать два контекста:
1. Внедрения типовых с доработками
2. Собственная/тиражная разработка

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

Как говорил Маркс: "бытие определяет сознание" )

ps Пардон за капитанство. Я не очень сообразительный ) Подозреваю все это терлось уже вдоль и поперек в сообществе.

36. пользователь 23.01.19 10:12

Сообщение было скрыто модератором.

...

38. 1ceo_2015 24.01.19 14:45 Сейчас в теме

(26)

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

Смотрите: в обоих плеерах починили возможность отображения произвольного текста после названия сценария согласно документации: https://docs.cucumber.io/gherkin/reference/#descriptions
https://github.com/silverbulleters/add/issues/323
https://github.com/Pr-Mex/vanessa-automation/issues/56

Зачем это нужно и почему это важно для фичеписателей и клиентов?
В этом произвольном тексте бизнес-аналитик (он же фичеписатель) конкретизирует критерий приемки на понятном для клиента языке.
Таким образом имеем первую итерацию сценария после общения с клиентом:

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

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

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

Можно построить story-map и разложить фичи по папкам согласно пользовательским активностям.
Можно пометить тегами и ими структурировать отчет аллюра.

Но самое главное, чтобы клиент это видел и понимал. Если не понимает и не видит - тогда пофигу все эти уровни детализации и произвольные тексты и кликерство.
Но это уже другая история. Руководителя проекта ;)"

Ответить

39. tsukanov 24.01.19 22:02 Сейчас в теме

(38) Мне кажется вы не поняли о чем я писал.

Мы не с клиентом работаем, а между собой (покрываем систему тестами).
Фичи пишет тестировщик, а программер ему помогает. Вопрос был в этом.

Взаимодействие с клиентом через геркин меня вообще не интересует.

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

ps В любом случае спасибо что поделились опытом

Ведь геркин это код

Спорное утверждение

41. oleynik.dv 164 25.01.19 12:11 Сейчас в теме

(39) К сожалению вы не поняли зачем Геркин :-(

Фичи пишет тестировщик, а программер ему помогает. Вопрос был в этом.

Это просто с ног на голову. Тестировщик пишет тест-кейсы. А фичи пишет бизнес-аналитик по результату сбора требований. Если у вас задача обкладывать готовый функционал тестами - то используйте (как вы и делаете) соответствующие инструменты (Тестер или Тестирование 3 или всё то же Сценарное тестирование).

Геркин он из BDD. Решается знаменитая проблема нахождения единого языка общения между бизнесом (как минимум бизнес-аналитиком, а в идеале стекйкхолдером), разработчиком и тестировщиком (three amigos):

Если у вас нет таких задач, то вам как говорится "Геркин не нужен!".

42. tsukanov 25.01.19 14:22 Сейчас в теме

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

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

ps В 1С тоже не понимают зачем геркин, когда прикручивают его к СППР?

44. oleynik.dv 164 25.01.19 16:51 Сейчас в теме

(42) "Человек с молотком во всём видит гвоздь" (с)
Меня в институте учили, что для каждой специфической операции есть специальный инструмент.
Наверное, на матлабе можно сделать учётную систему. Но зачем?
Gherkin был придуман для BDD (Дэн Норт, Аслак Хилесой и иже с ними).
Пришёл Алексей Лустин и создал волну движухи "За BDD в 1С!". И на фоне этой движухи произошла подмена понятий: из языка формализации требований Gherkin стали превращать в язык автотестирования, коим он изначально не являлся и не является. Именно поэтому так тяжело идёт. Всем интересно, но как до дела - так и масса вопросов, нюансов и подводных камней. А ответов нет. А всё потому что не по назначению используется.

Поэтому если стоит вопрос обкладывания готового функционала тестами - надо решать её соответствующими инструментами (выше о них написал). И разработчикам легче в голову ложится, и поддерживать тесты проще, и методики и документация есть.
А если есть задача: отстроить проектное внедрение по Scrum - тогда User Story, Feature и Gherkin inside. С демонстрацией заказчику прироста полезной функциональности зелёными сценариями в Allure. О чём выше и написал 1ceo_2015 (за что и получил непонятые вами плюсы).

Что касается СППР и Gherkin. Сама тенденция не может не радовать. Но, насколько я знаю, если держать в голове тот факт, что разработка продукта в СППР оторвана от сценариев на Gherkin, то всё становится не так радужно. То есть в СППР 2 есть функциональная модель, по которой ведётся дальнейшая разработка, а сбоку есть некие бизнес-процессы, в узлах которых сидит турбо-геркин. То есть по сути левая рука не ведает о том, что творит правая. К сожалению, пресловутая подмена понятий перекочевала и в СППР. Методик, как применять СППР на проектах внедрения я тоже не услышал (на семинаре ERP).

По поводу Gherkin в СППР у нас с Pr-Mex идут жаркие дискуссии. Вот он кстати внизу вписался. Может дать обратную связь или поправить меня про СППР (если это не коммерческая тайна конечно же).

45. tsukanov 25.01.19 17:26 Сейчас в теме

(44) Аминь, пусть так. Не готов вести диалог о тестировании на таком уровне (жалко времени).
Мне эти холиворы не интересны.

Скажите, а сколько вы написали тестов в формате геркин? Сколько функционала покрыли таким способом?
Поделитесь опытом

ps И да, меня в институте учили совершенно другому.

47. oleynik.dv 164 25.01.19 18:34 Сейчас в теме

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

Тесты и покрытие - это не про Gherkin . Мы не тестируем готовый функционал. А разрабатываем новый по сценариям поведения пользователей. Сейчас заканчиваем второй проект внедрения, в котором ставим цель разработки по BDD. Идеального результата нет, и ответов на все вопросы, как это делать правильно тоже нет. Поскольку применять BDD в проектах внедрения/кастомизации тиражного продукта - это тоже нетривиальное использование инструмента, заточенного под продуктовую разработку.

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

49. tsukanov 25.01.19 19:01 Сейчас в теме

(47)

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

Слабо понял. структуры - это что? примеры - это что?

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

50. oleynik.dv 164 25.01.19 19:35 Сейчас в теме

(49) я не успеваю писать статьи :-(
Максимум на комментарии хватает.
Да и поскольку законченного результата (которого все требуют в качестве пруфов) пока нет, то и писать неловко.

Посмотрите в профиле мою единственную (увы) статью. Там есть примеры структур сценариев.
Ну и есть вот этот очень полезный текст What's in a story (если с английским больно - вверху статьи есть ссылка на мой вольный перевод). Мы руководствуемся принципами из этой статьи.
Вот это по синтаксису Gherkin хорошо расписано.

54. tsukanov 25.01.19 23:01 Сейчас в теме

(50)

Да и поскольку законченного результата (которого все требуют в качестве пруфов) пока нет, то и писать неловко.

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

То что это работает в простейших случаях никто не сомневается (вашу статью посмотрел).
Непонятно как это делать в промышленных масштабах.

Статей и примеров детских я видел уже кучу. Проблема в том, что в реальности сценарии на порядок сложнее. Разложить все на микросценарии (как в примерах) тоже не видится возможным. Писать высокоуровневые фичи кажется по ресурсам нереальным (потому как тут вовлекается на фултайм как минимум 2 человека). И т.д. и т.п. Теория звучит заманчиво, но реальность с ней чет не очень стыкуется.

Я так понимаю что кроме как в СППР, никто так и не продемонстрирует кунгфу.

55. oleynik.dv 164 26.01.19 02:34 Сейчас в теме

(54) объясняю, почему топлю за трушность BDD.

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

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

Какие вижу варианты выхода из ситуации:
1. Не обновляться никогда. У нас есть клиенты до сих пор живущие на УТ 11.1, и им этого хватает. Древние УПП без ведения регл. учёта. Из глобальных изменений - 20% НДС. Здесь обкладывание готового функционала сценариями как процесс фиче-реинжиниринга имеет место быть. Ну то есть обложили сценариями готовый функционал - и дальше уже можно BDD-ить по полной.
2. Нужно на этапе внедрения вводить свою интерфейсную прослойку. И на её основе писать сценарии. Собственный рабочий стол под каждую роль (не в терминах 1С) в системе, разнообразные АРМ, фоном использующие типовой функционал. При таком подходе не нужно будет чинить сценарии после обновления, поскольку бизнес-логика не поменяется. Нужно будет адаптировать прослойку под новый функционал типового решения. Но это нормальная работа программистов. То есть покрасневшие сценарии будут нам показывать проблемы адаптации прослойки к новому типовому функционалу, а не проблемы реализации сценариев, потому что документ "Поступление" в 2.4 стал называться "Приобретением".
3. Фирма 1С начинает разрабатывать типовые продукты по BDD и на выходе вместе с очередным релизом выдаёт пачку сценариев на Gherkin, которые на некой эталонной базе зеленеют в Allure. Это не даёт ясности в том, как жить после обновления кастомизированной конфигурации, зато даёт отличную базу для регрессии. И здесь вся надежда на СППР и Pr-Mex.

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

Ответить

58. tsukanov 26.01.19 13:40 Сейчас в теме

(55) Спасибо за развернутый ответ!
Прям ощутил вашу боль. Сам работал раньше на внедрениях и допилах типовых.
Но сейчас у меня ситуация не похожа на вашу. Тиражная разработка. Соответственно новый функционал обычно затрагивает сразу многие объекты в конфе. И даже если вообразить, что мы делаем это под конкретного юзера, то проблема все равно остается. Объем даже простейших тестов получается не маленьким. Хоть ты сквозной бизнес-процесс прогоняй в минимальном варианте, хоть россыпь мини BDDшек. Есть куча вопросов организационного и чисто технического плана. И мы пытаемся организоваться ведь не в вакууме. Есть ограничения на ресурсы, есть особенности командного состава, есть устоявшиеся практики. Хочется чтобы пакет тестов понимали все участники, чтобы можно было понимать что у нас покрыто тестами а что нет, и много других чтобы...
И вопрос использовать BDD или нет вообще не стоит. Мы решаем свою конкретную проблему в своей системе координат. Ванесса заинтересовала банально тем, что гипотетически сценарии может понять любой участник без доп. подготовки (хотя это пока вызывает сомнения). Т.е. мы смотрим только на определенные свойства инструмента, а все аббревиатуры оставляем за дверью. Нам не важно как будет называться методика (и есть ли вообще название), на рельсы которой мы встанем в итоге. Нам важно получить адекватный нашей реальности подход.

63. grumagargler 726 28.01.19 20:17 Сейчас в теме

(55)

Соответственно, каждый игрок на этом рынке, обкладывающий готовый функционал сценариями на Gherkin, живёт на пороховой бочке из свежих релизов типовых решений (с переименованием общих модулей, объектов метаданных, не говоря уже о реквизитах и формах)

И встает вопрос - что же это за инструмент тестирования такой, который фактически вынуждает вас вместо эволюции продукта, хоронить его под вашими тестами? То есть получается, что для кода, который вы не писали, у вас не хватает сил изменить тесты, а что если вам этот код еще и писать придётся, это же еще больше сил хватать не будет! На мой взгляд проблемы, которые решает bdd важны, но уж сильно переоценены. У каждого своя статистика, но моя говорит о том, что проблемы в продуктах существенно чаще связаны с чистыми ошибками, недосмотрами, и недостаточным качеством тестирования, и совсем не часто с тем, что кто-то кого-то не понял.
По поводу покрытия готового функционала. Как раз описываемый bdd-инструментаций, по факту, и выводит тестирование уже готового функционала. Вести разработку (программирование) с такими инструментами очень сложно, начиная от перезапусков приложения и заканчивая подготовкой тестовых данных, а в тестере - этот процесс бесшовный. То, что должен делать функционал - легко описывается в комментарии, а дальше - чистый код, без особенностей поведения.
Я прочитал последнюю статью Владимира. Парни, вы всерьёз утверждаете, что овладеть технологией в состоянии простой тестировщик, что всем всё понятно, и такие шаги как “И я запоминаю значение поля с именем "Дата" как "ДатаДокумента"” не являются артефактом того, что подход протекает под реальностью?

64. tsukanov 28.01.19 21:58 Сейчас в теме

(63)

То есть получается, что для кода, который вы не писали, у вас не хватает сил изменить тесты, а что если вам этот код еще и писать придётся, это же еще больше сил хватать не будет!

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

65. grumagargler 726 28.01.19 22:13 Сейчас в теме

(64)

Но ведь это “дано”. Это именно то, что в 90% случаев и приходится делать, и соответственно - тестировать. Не требуется покрывать своими тестами типовой функционал, достаточно иметь тесты-методы, которые будут создавать нужные данные по необходимости, и инструментарий должен легко давать возможность менять эти тесты без страха перед изменениями, ведь для этого тесты и существуют - не бояться менять/развивать функционал. И не все доработки заканчиваются добавлением новых объектов. А что если нужно тестировать измененный типовой документ, писать тест или нет? Если писать - значит получается очередное обновление (что норма) - это большая проблема восстановить работоспособность тестов.

66. tsukanov 28.01.19 22:33 Сейчас в теме

(65)

Не требуется покрывать своими тестами типовой функционал

Ну я в общем то о том же )

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

ps Ну или я уже вообще не соображаю, пардон

67. grumagargler 726 28.01.19 22:47 Сейчас в теме

(66)

ps Ну или я уже вообще не соображаю, пардон

Как по мне, всё отлично вы соображаете и задаете острые вопросы, которые многие стесняются задавать.
Конечно, прийти на работу и сесть за написание тестов покрытия функционала типовой, неправильно, думаю об этом и речи ни у кого нет. Но, не писать тесты для покрытия своего функционала, которые затрагивают типовые объекты - нельзя, иначе о каком тестировании речь. Если добавляется движение в документ ПоступлениеТоваров, то проверить эту доработку без создания теста для типового ПоступлениеТоваров - нельзя. И то, что этот документ, будет меняться от релиза к релизу - это совсем не новость, не сложность, и ни что иное - как нормальная ситуация, и если инструментарий + методика к этому не готовы, или готовы настолько, чтобы не делать эти обновления, тогда нельзя говорить о продуктивном тестировании.

68. Vladimir Litvinenko 2896 28.01.19 22:49 Сейчас в теме

(66) Представьте себе торговую компанию. Работа 24/7, точки по всей России. Типовая конфигурация с доработками. Критичные операции - закупка , перемещение, заказ клиента и реализация товара.

Допустим мы доработали документ "Реализация товаров и услуг". Одновременно с ним доработка коснулась складского учета. Планируются дальнейшие доработки типовых модулей складского учета и методов модулей, которые задействованы в различных типовых механизмах.

Следует ли при этом написать хотя бы несколько функциональных тестов на процесс заказа товара клиентом, перемещения товаров и процесс поступления товаров?

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

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

Вот если фирма 1С сама начнёт выпускать такие тесты для типовых механизмов - вот это будет классно и решит эту проблему без дополнительных затрат.

69. oleynik.dv 164 29.01.19 00:49 Сейчас в теме

(63) Дмитрий, совершенно верно: у каждого своя статистика. И свои проблемы (в том числе и финансовые), над решением которых мы работаем.
Нам важно НЕ слышать от заказчика фразу: "то, что вы сделали работает, но это не то, что мне нужно...", потому что после такой фразы заказчик плохо платит.
Для вас же эта антифраза, по-моему (я много читал вас на infostart), звучит так: "вы сделали то, что мне нужно, на как это всё глючит...".

Если упростить workflow разработки до вида:
1. Бизнес-анализ
2. Формализация требований
3. Разработка
4. Тестирование
то нас интересует (и в чём мы видим, прости Господи, challenge) в большей степени 1, 2 и 3. Для вас же, как мне кажется, в приоритете 3 и 4. То есть "что нужно реализовать" - у вас с этим всё чётко и понятно, осталось реализовать и протестировать. А у нас проблема понять мутного и нечёткого заказчика, вывести его на проверяемые критерии приёмки по его хотелкам, и после реализации убедиться в том, что критерии приёмки реализованы в разработанном функционале.

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

То есть вот та низовая техника работы с Vanessa, которую описывает Владимир - это как бы must have, но не core feature. Человекочитаемые, основанные на примерах сценарии, ориентированные на заказчика - вот то, ради чего, на мой взгляд, стоит пользоваться Vanessa. Если это не нужно, и нет такой проблемы и задачи - то конечно надо пользоваться вашим тестером. Он намного ближе программисту и тестировщику, и те самые проблемы изменяющихся эталонных данных, обхода последствий обновления конфигурации у вас проработаны методически лучше (о чём я уже писал выше).

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

P.S.
Что до проблемы с обновлением - мы работаем над этим, это своего рода творческий процесс. Как разрабатывать, и как оформить сценарии, чтобы это было устойчиво к обновлению. Ещё пара мучительных обновлений и ~~я сойду с ума~~ будет выработана какая-то методика.

P.P.S.
При достаточном финансировании было бы даже интересно провести эксперимент с комбинированием использования Vanessa и Тестер на одном проекте. Чтобы на каждом этапе упрощенного workflow применялся подходящий для него инструмент.

70. grumagargler 726 29.01.19 01:23 Сейчас в теме

(69)

Если упростить workflow разработки до вида:
1. Бизнес-анализ
2. Формализация требований
3. Разработка
4. Тестирование
то нас интересует (и в чём мы видим, прости Господи, challenge) в большей степени 1, 2 и 3. Для вас же, как мне кажется, в приоритете 3 и 4. То есть "что нужно реализовать" - у вас с этим всё чётко и понятно, осталось реализовать и протестировать.

Верно. Но сказать, что у нас совсем нет проблем с 1 и 2, значит солгать. Проблемы есть, но нам никогда не удавалось их успешно формализовывать. Формализовать - можно, успешно в общем смысле этого слова - нет. Можно доказать, что заказчик это и просил, и заставить его рассчитаться, но это не делает нас лучше, если мы по факту, не уловили исходную проблематику (оставим за скобками непорядочных клиентов). Поэтому, кроме, понятное дело, воспитания у себя чувства задачи, мы решили сместить проблемы такого рода в процесс разработки, чтобы развязать себе руки используя гибкие средства по тестированию, чтобы делать задачи не по принципу “не навредить”, и по принципу - как это должно быть, чтобы не бояться перекраивать код, как решения, так и тестов, ведь согласитесь, в больших проектах, значительно чаще возникает страх что-то сломать, чем изменить. Поэтому, когда функционал приклеивается тестами в силу сложности их создания/модификации, я нахожу это противоречивым самой идее тестирования.

71. Pr-Mex 136 29.01.19 13:59 Сейчас в теме

(63)

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

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

72. Pr-Mex 136 29.01.19 14:00 Сейчас в теме

(63)

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

Расскажите, что вам мешает сделать "бесшовным" процесс разработки в Ванессе?

73. Pr-Mex 136 29.01.19 14:02 Сейчас в теме

(63)

Я прочитал последнюю статью Владимира. Парни, вы всерьёз утверждаете, что овладеть технологией в состоянии простой тестировщик, что всем всё понятно, и такие шаги как “И я запоминаю значение поля с именем "Дата" как "ДатаДокумента"” не являются артефактом того, что подход протекает под реальностью?

Да, простой тестировщик (в том числе без навыков программирования) легко осваивает.

74. 1ceo_2015 29.01.19 15:56 Сейчас в теме

(73)

Да, простой тестировщик (в том числе без навыков программирования) легко осваивает.

Приходит секретарша устраиваться на работу:
HR у нее спрашивает: с какой скоростью печатаете?
С: - 10 000 знаков в минуту?
HR: -ЧТО, правда???
C: - правда. Но такая херня получается...

освоить кликерство оно конечно просто. Главное тут освоить осмысленное кликерство имхо ;)

Интересен кейс когда один такой кликер уволился и вместо него посадили другого кликера. И еще произошло обновление с 2.4.2 до 2.4.7 и тесты на этом ГеркинАссемблере упали и надо понять это они упали или функционал.
Такой опыт у кого-то был?

75. Pr-Mex 136 30.01.19 09:27 Сейчас в теме

(74)
У нас тестировщик - это ещё методолог в своей области.
Он хорошо понимает, что там происходит.

А чтобы сценарий не превращался в стену текста - существует практика кодревью.

76. 1ceo_2015 30.01.19 13:15 Сейчас в теме

(75) Леонид, я другой кейс уточнял. Передачу контекста между тестировщиками в случае критического обновления конфы.
Когда один тестировщик и он методолог и вечный раб компании - это идеальный вариант из идеального мира))

80. tsukanov 31.01.19 12:14 Сейчас в теме

(73) Минус походу ткнул простой тестировщик )))

Ну а вообще простой тестировщик и программирование легко осваивает.
Объективных экспериментов и сравнения (что легче) вроде никто не публиковал.

52. Pr-Mex 136 25.01.19 19:56 Сейчас в теме

(47)
Тут, на мой взгляд, подмена понятий происходит.
Инструментарий на геркине позволяет реализовывать в жизнь и такие и такие подходы.
И создавать сценари от верхнеуровневых требований - тогда речь про BDD.
И просто покрыть сценариями то, что уже есть. Это просто тестирование.

У вас же была на сайте статья, как вы используете BDD. Скинешь ссылку?

57. oleynik.dv 164 26.01.19 03:01 Сейчас в теме

(52) К пуговицам претензий нет ;-)
Инструмент хороший и с каждым релизом всё хорошеет.
А статья была про то, как мы пытаемся разрабатывать по BDD, и как у нас это НЕ получается.
Про подходы написал в (55).

46. Pr-Mex 136 25.01.19 17:36 Сейчас в теме

(44)
Сценарии в СППР связаны с функциональной моделью.
Также в СППР есть средства для моделирования и запуска бизнес-процессов.
Похоже, ты не очень в теме как оно там устроено )

48. oleynik.dv 164 25.01.19 18:35 Сейчас в теме

(46) Покажешь на партнёрке ;-)

51. Pr-Mex 136 25.01.19 19:53 Сейчас в теме

(48)
Приходи. И все кому интересна эта тема, тоже приходите.

53. tsukanov 25.01.19 20:25 Сейчас в теме

(44) В порядке смолтока (типа на перекуре):
Вот вы набежали в комменты и судя по всему записали меня в какой-то лагерь.
Шутка юмора в том, что я не принадлежу никакому лагерю и никакой идеологии.
Все эти ваши BDD, TDD, User Story, Геркины, Лустины, Нортоны....
Как бы вам сказать... Для меня все это шелуха. И все эти идеологические вопросы и кто по какой модной аббревиатуре работает или тестирует - все это не важно.
Я постигал программерское ремесло совершенно другим способом. И тестирование для меня - это просто искусство тыкать палкой. А базируется мое представление на том, что писал Дейкстра (и многие другие пионеры).
Возможно вы будете удивлены, но понятия "предусловие" и "постусловие" известны многим образованным людям очень давно. И вот когда эти люди всю профессиональную жизнь оперировали этими понятиями, а им начинают втирать про идеологию BDD....
Наверно не надо объяснять как глупо это выглядит со стороны? )

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

А все потому что:
1. Формальный подход, который позаимствовал BDD существует как минимум с 70х
2. Все, кто читает первоисточники, о нем знают уже цать лет (почти вся пионерская работа активно переводилась в союзе).
3. Самое вкусное - этот подход же совершенно очевиден. Иначе тестить и нельзя вовсе.

И вот с какого перепугу я должен перестать мыслить в исходных категориях и начать с вами тереть какие три буквы идеологически верней?

Надеюсь мне удалось показать world in my eyes ) Так будет больше взаимопонимания.

56. oleynik.dv 164 26.01.19 02:53 Сейчас в теме

(53) Да бросьте вы, какие лагеря и три буквы... ;-)

Если человек мыслит в терминах:

|предусловие|действие|постусловие|

то это наш человек ))).

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

Ситуация сейчас напоминает вот эту картинку из блога Асхата Уразбаева:

Собственно, на фоне этой картинки и ситуации из меня так много текста )

59. tsukanov 26.01.19 14:01 Сейчас в теме

(56) Понимаю ваше негодование )

Правда есть один тонкий момент. Подобную картинку (в нашем контексте) можно понимать двояко:
1. Нарушение принципов BDD
2. Нарушение принципов тестирования как такового

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

И вот теперь, когда все прояснилось, перечитайте о чем я спрашивал в самом начале (26) :)

43. Pr-Mex 136 25.01.19 14:44 Сейчас в теме

(41)
Обкладывать тестами готовый функционал можно на чём угодно. И с помощью Геркина и без него.

40. tsukanov 25.01.19 11:48 Сейчас в теме

(38) Удивительно что ваш комментарий плюсуют. Ведь он абсолютно мимо кассы. Без обид.
Сломанный телефон какой-то. Видимо мне стоит как нибудь выделить время и разобрать все по косточкам так, чтобы не было не единого шанса появляться комментам, подобным вашему.

Совершенно парадоксальное недопонимание. Прям как с синезолотым платьем.

27. tormozit 7229 21.01.19 22:40 Сейчас в теме

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

30. grumagargler 726 22.01.19 01:54 Сейчас в теме

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

Требовать от разработчиков при этом еще и бесплатных курсов и всеобъемлющей документации несправедливо.

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

Я это делаю через специальный этап сборочной линии - подготовка тестовых данных. Разворачиваю тестовую базу из копии рабочей (да да из копии рабочей, потому что программисты накодили там поиск по наименованию, кое где вшиты GUID и прочий хардкод, алгоритмы зависят от текущей даты, просто так маленькую демо базу не сделать). Затем запускаю обработку инициализации - она готовит пользователей, сбрасывает пароли. Затем стартовые сценарии - подготовка тестовых данных.

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

31. Vladimir Litvinenko 2896 22.01.19 02:42 Сейчас в теме

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

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

32. grumagargler 726 22.01.19 05:09 Сейчас в теме

(31)

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

Есть ли пункт, который не получилось проработать руками по тексту статьи?

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

77. user670203_terskovaoa 30.01.19 14:46 Сейчас в теме

При запуске Vanessa Behavior не запускается запись действий пользователя, появляется ошибка "Значение не является значением объектного типа (ДопПараметры)" и еще вот это "30.01.2019 14:45:40 Не найден TestClient для подключения."
Подскажите пожалуйста что не так?

78. Vladimir Litvinenko 2896 30.01.19 17:56 Сейчас в теме

(77) Этой информации мало, чтобы сделать какие-то предположения о причинах такого поведения.
Запись действий пользователя всё же не должна запускаться при запуске Vanessa Behavior. Она должна запускаться отдельной командой. Нужно более точно описать момент возникновения проблемы - при запуске VB или при нажатии на кнопку записи действий пользователя.
Также не помешал бы скриншот, иначе долго гадать будем.

79. user670203_terskovaoa 31.01.19 09:29 Сейчас в теме

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

Прикрепленные файлы:

81. Vladimir Litvinenko 2896 31.01.19 16:49 Сейчас в теме

(79) Ошибка может быть как в VB, так и в тестируемом приложении. Нужен стек исключения. А лучше отладчик подключить.

Вообще окно VB выглядит странно. В нём нет информации о версии. Заголовок должен быть похож на "ver 5.6.0: Vanessa Behavior". А у вас там написано просто Vanessa Behavior. Похоже, что либо установка некорректно прошла либо какая-то старая версия установлена.

82. user670203_terskovaoa 31.01.19 16:59 Сейчас в теме

Спасибо. Устанавливала, через 1script. Попробую еще раз установить.

83. user670203_terskovaoa 12.02.19 10:09 Сейчас в теме

Добрый день. Переустановила несколько раз, все по инструкции, но при открытии bddRunner.epf появляются два окошка и она не запускается так как нужно.

Прикрепленные файлы:

85. Vladimir Litvinenko 2896 12.02.19 10:28 Сейчас в теме

(83) (83) В публикации есть раздел

"Необходимые права на установку библиотек OneScript и настройка прав на запуск внешних обработок"

В нём описано, что необходимо сделать, чтобы избавиться от этого предупреждающего окна. Также информация есть на ИТС здесь: https://its.1c.ru/db/v838doc#bookmark:dev:TI000001873

84. user670203_terskovaoa 12.02.19 10:09 Сейчас в теме

Подскажите пожалуйста что я делаю не так????

86. user670203_terskovaoa 12.02.19 10:59 Сейчас в теме

Спасибо.

87. nvv1970 03.03.19 23:35 Сейчас в теме

Коллеги, просветите: откуда название пошло Vanessa ? ))

88. Vladimir Litvinenko 2896 04.03.19 10:52 Сейчас в теме

(87) Насколько мне известно, отсюда https://ru.wikipedia.org/wiki/Ванессы

91. nvv1970 19.03.19 13:10 Сейчас в теме

(88) Уан эс са = One S 'a = 1C
Как же я сразу не допер )

89. NightBreez 79 13.03.19 11:33 Сейчас в теме

А когда ожидать следующую публикацию ? Очень интересно посмотреть примеры про тестирование обмена в РИБ.

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

(89) Ссылки на три следующие части можно найти в профиле.

92. for_sale 976 06.05.19 17:23 Сейчас в теме

Большое спасибо за статьи, очень ценный материал.

Есть вопросы, пожелания и предложения))

1. Открыл обработку, включил УИ, записал сценарий, жму Подготовить сценарий. Вываливается ошибка о том, что папка Ц-Юзерс-итакдалее\Temp\vanessa-add не найдена. Оказалось, что темповый файл пытается туда записать, хотя эту папку никто не создавал.

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

3. Простой пример вопросов - у нас в разрабатываемом модуле есть версии. И эти версии выводятся в заголовок окна. Соответственно, если писать сценарий "И я открываю окно ""Обработка в.1""", то завтра этот сценарий надо будет переписать на "И я открываю окно ""Обработка в.2""". Есть ли возможность указывать что-то вроде "Окно, имя которого начинается на "Обработка в."". Если нет, то как это создать?

4. По циклу статей. Автору за труд - низкий поклон. Но всё же материал довольно путанно изложен и длина текста просто нереальная. Вначале идёт пример, потом установка, потом постянные отсылки к примеру, всё это промежается геркином и настройками. В результате приходится бегать между статьями, одни абзацы пропускать, другие искать и т.п. Может разбить материалы на статьи длиной 10001 символ (иф ю ноу ват ай мин) и пронумеровать их в том порядке, в котором человек, который вообще ничего не знает по теме, мог бы, постепенно сталкиваясь с функционалом, его гармонично познавать? Заодно тогда можно было бы задавать вопросы по конкретной небольшой части, что и комментарии бы сделало полезным источником информации, где реально что-то найти. Очень не хочу обидеть автора, действительно, труд титанический. Просто конструктивное предложение, как этот труд заставить служить людям ещё более эффективно :)

93. for_sale 976 06.05.19 18:28 Сейчас в теме

(92)
И ещё вопрос - как сделать простой цикл проверки? Например, открывается форма, в неё грузится что-то, форма пока не доступна (у элементов через код выключена доступность), через пару секунд всё загрузилось и доступность у элементов появляется. Как можно установить примерно такой цикл:

Пока Истина Цикл
Если у элемента "Имя" доступность = Истина Тогда
Прервать
Иначе
Пауза 1

Как при этом ограничить тело цикла, чтобы следующие строки не считались (или наоборот, считались) продолжением кода в цикле и в разделе Иначе? (т.е. есть ли какой-то аналог директив КонецЦикла и КонецЕсли?)

94. for_sale 976 06.05.19 18:40 Сейчас в теме

Ещё вопрос по принципу разработки шагов.

Шаг полностью создаётся разработчиками или пользователем Ванессы или же есть какие-то служебные операторы (если тогда иначе цикл пока для каждого), и разработка шага - это только разработка проверки условия?

Например, я хочу иметь шаги
1. Если Погода = -30ИСнег Тогда
2. Пока Погода = -30ИСнег Цикл

Мне нужно разработать оба шага в описанном виде или же можно сделать шаг, который будет проверять условие Погода = -30ИСнег, а дальше я просто делаю конструкции
Если <МойШагПроПогоду> Тогда
Пока <МойШагПроПогоду> Цикл
?

95. for_sale 976 06.05.19 18:45 Сейчас в теме

(92)
Отвечаю на свой же вопрос:

3. Простой пример вопросов - у нас в разрабатываемом модуле есть версии. И эти версии выводятся в заголовок окна. Соответственно, если писать сценарий "И я открываю окно ""Обработка в.1""", то завтра этот сценарий надо будет переписать на "И я открываю окно ""Обработка в.2""". Есть ли возможность указывать что-то вроде "Окно, имя которого начинается на "Обработка в."". Если нет, то как это создать?

В параметре, описывающем заголовок формы, можно использовать символы подстановки ? (любой один символ) и * (любая последовательность символов). Т.е. можно написать "Обработка в.*" или "Обработка в.2.?"

96. user1415340 29.05.20 13:35 Сейчас в теме

Добрый день.

Использую Vanessa ADD ver.6.5.0
При попытке "подключить выбранного клиента тестирования" выходит ошибка "28.05.2020 17:22:17 {ВнешняяОбработка.bddRunner.Форма.УправляемаяФорма.Форма(15912)}: Ошибка при вызове метода контекста (Открыть): Файл не обнаружен 'C:\Users\vladimir\AppData\Local\Temp\17\v8_3877_11.txt'".
Захожу в папку там нет этого файла есть а последние появившиеся v8_3877_12.bat и перед ним v8_3877_10.txt
В чём может быть проблема с подключением?

Заранее спасибо.

97. HostHost 287 31.05.20 20:56 Сейчас в теме

Добрый день, Владимир! Не сочтите за занудство, Для VSC расширение Gherkin step autocomplete уже не светится в списке доступных. Ссылка https://github.com/silverbulleters/gherkin-autocomplete не открывается. Если есть доступный аналог, было бы не плохо, поделитесь информацией. Спасибо за отличную статью!

98. G_109911886901141245786 25.03.21 15:58 Сейчас в теме

У меня Vanessa сразу не запустилась в 1С

Прикрепленные файлы:

99. user749176 27.10.21 15:50 Сейчас в теме

на моменте загрузки библиотек ошибка

C:\Program Files\OneScript\lib>opm list
Установленные пакеты:
-----------------------------------------------------------------
Пакет | Версия | Имена серверов
-----------------------------------------------------------------
1commands | 1.5.0 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
asserts | 0.4.0 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
cli | 0.9.10 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
datetime | 0.1.0 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
delegate | 0.2.0 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
fluent | 0.4.0 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
fs | 0.5.0 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
json | 1.1.1 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
logos | 1.1.1 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
notify | 0.2.0 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
opm | <НЕТ> | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
reflector | 0.5.1 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
semver | 0.5.2 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
strings | 0.4.1 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
tempfiles | 0.2.2 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
v8find | 0.1.2 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
v8runner | 1.5.0 | ОсновнойСерверПакетов, ЗапаснойСерверПакетов
-----------------------------------------------------------------
Пакет | Версия | Имена серверов
-----------------------------------------------------------------

C:\Program Files\OneScript\lib>where opm
C:\Program Files\OneScript\bin\opm.bat

C:\Program Files\OneScript\lib>opm install --all
ИНФОРМАЦИЯ - Скачиваю файл: os-amazonmws.ospx
ПРЕДУПРЕЖДЕНИЕ - Обрабатываю возникшую ошибку...
{Модуль C:\Program Files\OneScript\lib\opm\src\core\Классы\МенеджерУстановкиПаке
тов.os / Ошибка в строке: 136 / {Модуль C:\Program Files\OneScript\lib\opm\src\c
ore\Классы\УстановкаПакета.os / Ошибка в строке: 108 / Внешнее исключение (Syste
m.UnauthorizedAccessException): Отказано в доступе по пути "C:\Program Files\One
Script\lib\os-amazonmws".}}

C:\Program Files\OneScript\lib>opm install add
ИНФОРМАЦИЯ - Скачиваю файл: add.ospx
ПРЕДУПРЕЖДЕНИЕ - Обрабатываю возникшую ошибку...
{Модуль C:\Program Files\OneScript\lib\opm\src\core\Классы\МенеджерУстановкиПаке
тов.os / Ошибка в строке: 136 / {Модуль C:\Program Files\OneScript\lib\opm\src\c
ore\Классы\УстановкаПакета.os / Ошибка в строке: 108 / Внешнее исключение (Syste
m.UnauthorizedAccessException): Отказано в доступе по пути "C:\Program Files\One
Script\lib\add".}}

C:\Program Files\OneScript\lib>

Оставьте свое сообщение

E-mail:

Автор:

Владимир Литвиненко (Vladimir Litvinenko)

Рейтинг: 2896

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

Публикация:

№ 974944

Создание 21.01.19 00:52

Обновление 24.02.19 20:58

Статистика:

Просмотры 74269

Загрузки 0

Рейтинг 258

Комментарии 99

Характеристики:

Код открыт Да

Рубрики Тестирование QA

Кому Программист

Тип файла Нет файла

Платформа Не имеет значения

Конфигурация Не имеет значения

Операционная система Не имеет значения

Страна Не имеет значения

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)