о да. еще в рэльсу можно ченить писнуть с теми же шансами на успех. нет уж, благодарю.

Форум бсп админю я, потому там лампово, к слову)

👍

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

голословные обвинения! и еще раз - это все про QA. Но мне кажется кто-то хочет помодерировать :))) Бохвпомощь

это про QA?

👍

Кстати, у меня нет доступа к ERP, но есть такая новость старая немного, но в тему чата

О публикации сценариев нагрузочных тестов для конфигурации "ERP Управление предприятием 2"
http://1c.ru/news/info.jsp?id=24500

простите за глупый вопрос, а для VA есть какой нибудь мануал, для тек кто не пользовался, с чего начать, как пользоваться, как отлаживать, как писать сценарии?) Спасибо

https://github.com/Pr-Mex/vanessa-automation там есть краткая инструкция

Более полная документация есть в родительском проекте:
https://github.com/silverbulleters/vanessa-behavior

спасибо!

Спасибище!!!!

1. Есть информация на странице проекта на гитхабе
2.  Есть внутренняя справка в самой обработке.

спасибо!

Расскажу свой взгляд на подготовку тестовых данных -  со стороны больших проектов.
1. Загрузкой данных из макетов мы не пользуемся. У этого подхода есть существенные минусы.
 1.1 Загрузка из макетов, имхо, подходит, когда метаданные очень стабильны и редко изменяются.
 1.2 Для типовых конфигураций, когда они активно разрабатываются и развиваются, такой механизм загрузки из макетов создаёт много лишних проблем.
 1.3 Данный механизм предполагает, что TestManager запущен в той же базе что и TestClient. Это не очень, т.к. например для ERP это означает, что придётся тратить ресурсы на запуск ещё одной сессии ERP, а это доп расходы по памяти, которые ложатся на облачную инфраструктуру, на которой происходит запуск тестов.
2. С другой сторны нам надо проверять работу обработчиков обновления, которые работают, при переходе между версиями.
3. Поэтому для запуска тестов используются заранее подготовленные DT файлы, которые обновляются на нужную версию ERP (при этом ещё раз проверяются обработчики обновления).
4. Т.к. для разных видов тестов нужно разное наполнение тестовыми данными, то существует несколько dt, которые уже предзаполнены под разные задачи: для бюжетирования своё, для видов запасов своё и т.д.
5. Также, само собой, во время работы тест сам создаёт недостающие данные, которые нужны для его работы.
6. У этого подхода есть минус - в git не остаётся истории изменения наполнения тестовых DT.
7. Но для нас плюсы (простота поддержки, дополнительные тесты обработчиков обновления, нет проблем с макетами данных, которые перестали работать из-за изменения метаданных) перевешивают этот минус.

Кому интересно  - задавайте вопросы.
Смогу ответить вечером.

По пункту 4 непонятно. Почему разное наполнение? Пользователь работает с единой базой...
Демо-база же тоже единая, а не "это для бюджетирования, это для производства..."

Разные функциональные опции.

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

тогда, получается, должны быть и сводный тест? Где включено все, условно (как в демо)

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