Size: a a a

2018 November 29

NM

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

Z

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

Z

ZEEGIN in testspro1c
Вы имеете ввиду сквозные тесты по подсистемам?
источник

Z

ZEEGIN in testspro1c
Но ведь все что может прийти от зависимых подподсистем уже приходит в виде эталонной базы...
источник

VP

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

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

И не разделяете ли вы демобазы по подсистемам? Например, производство отдельно, казначейство отдельно

А как-то проверяются внешние сервисы или обходитесь моками? (ЕГАИС, к примеру, или это уже отдельно)
источник

VP

Vitaly Popov in testspro1c
Anton Valkovskiy
А вот кто бы выложил пример реализации сценария на BDD в коде. Что бы правильно и красиво все было написано. А то сейчас умом все вроде понятно, да только не понятно, все ли делаешь красиво или костыли и велосипеды на самом деле метаешь.
Ну правильно/неправильно не скажу, но можно покритиковать на конкретном примере =)
источник

VP

Vitaly Popov in testspro1c
Мне например очень понраилась возможность экспортных сценариев. Чтобы свои шаги не через конфигуратор делать, а водном контексте с остальным тестом. Сильно уменьшает лапшевидность теста.
источник

VP

Vitaly Popov in testspro1c
Ну и в принципе лучше свои библиотеки не лениться писать...
Сильно потом облегчает жизнь
источник

AV

Anton Valkovskiy in testspro1c
Не, я имел ввиду не кнопнонажималку. Я имелл ввиду другое
источник

AV

Anton Valkovskiy in testspro1c
Сценарий, который приходит от аналитика например
источник

AV

Anton Valkovskiy in testspro1c
и шаги сценария уже реализоваываются программистом.
источник

AV

Anton Valkovskiy in testspro1c
С поддержкой экспортных шагов и всего такого.
источник

VP

Vitaly Popov in testspro1c
Аааа, не так понял =(
источник

AV

Anton Valkovskiy in testspro1c
С кнопконажималкой вроде особых сложностей нет )
источник

AV

Anton Valkovskiy in testspro1c
Но все равно спасибо )
источник

ВЕ

Виктор Ермаков... in testspro1c
Anton Valkovskiy
С кнопконажималкой вроде особых сложностей нет )
мне вот не понятно, как Вы узнаете когда пишите сценарий, какой слово поймет Геркин?))
источник

ВЕ

Виктор Ермаков... in testspro1c
а какое не поймет
источник

AV

Anton Valkovskiy in testspro1c
источник

AV

Anton Valkovskiy in testspro1c
Ну вот то что он должен по идее точно понять
источник

AV

Anton Valkovskiy in testspro1c
Остальное - экспортные скрипты
источник