Комментарии 10
А по выбору инструмента интересует, почему не рассматривали CBTA, почему не подошёл eCATT, и смотрели ли вообще UFT или TestComplete?
Про инструменты:
CBTA — мой косяк (опечатка, исправил), я вместо него написал TAO…
eCATT: это все же программирование (своего рода) на ABAP, не хотел туда углубляться (и «углублять» наших тестировщиков). Представьте сложные случаи — в нашем случае убыток по ПВУ создается руками примерно за 10 минут, уложить это в «портянку» на eCATT — вряд ли. Нужно будет что-то конструировать, что мы и сделали (вне SAP).
TestComplete (насколько я помню — уже года 4 прошло от начала) на тот момент не мог управлять SAP GUI напрямую, именно он использовался нашими тестировщиками для регресса всего остального нашего софта, и именно в нем они никак не могли тогда научиться тестировать SAP.
UFT и много другое смотрели «по диагонали» — в гугловой выдаче с минимальным погружением. Я искал простой, максимально универсальный и SAP-онезависимый способ. В процессе поиска мне показали, как из Excel-а заполняют документы (партнер SAP в каком-то из проектов для просто автоматизации рутинной операции), видя это желание осваивать какой-то лицензионно обременный продукт автоматизированного тестирования отошло на второй план.
А можете поделиться мнением и впечатлениями о CBTA? Очень актуально для меня сейчас… В плане лицензирования он идёт вместе с SolMan'ом, так что проблем нет, интересует именно ваш опыт…
В части GitHub — да, интересуют исходники библиотеки, было бы классно :)
Про CBTA — я ходил на однодневный семинар в SAP, внимательно слушал и вникал. Поймите меня правильно — давно это было, вот что осталось в памяти:
Свой большой мир. Чтобы начать тестировать (условно — создать убыток) нужно этот мир освоить и настроить под свою специфику. Это проходимо, но (мой случай) опыта в SAP было мало, для меня это был минус.
Ориентация на запись. Наши тестировщики на тот момент меня убедили — инструменты, которые «пишут» действия пользователя, неэффективны в долгой перспективе. Записанные скрипты сложно менять. Мне хотелось иметь инструмент, который позволяет оперировать с тестами как с программой (потенциально — генерировать ее), создавать свои абстракции и таким образом бороться со сложностью. Мне показалось (могу ошибаться — высказываю свое мнение), что CBTA таких возможностей не представляет.
Представьте себе: как Вы будете обсуждать с бизнесом сценарий использования планируемой доработки в случае использования CBTA? Я, конечно, в ATDD полез, но эта мысль/цель тогда тоже была. В случае робота мы прямо из ВЕБ интерфейса печатаем текст и идем обсуждать, «крыжить» по бумажке. А потом наращиваем этот текст реальным «мясом»…
Кстати, Gherkin не рассматривали как аналог языка скриптов?
Нет, не изобретали. Да, рассматривали…
Робот ориентирован на BDD, ниже процитирую из документации Robot Framework (сорри за английский), а от себя так — да, я перевел все свои автотесты по той веб разработке, которую упоминал, в этот формат. Он структурирует "поток сознания", мне понравилось. Бизнес впрочем не понял такого переформатирования и остался равнодушен (кстати, типично)...
Наверное это не прозвучало в статье, робот — достаточно серьезная разработка, они проводят конференции пользователей, развивают его — живой продукт. Рекомендую (как миниум посмотреть).
Цитата:
It is also possible to write test cases as requirements that also non-technical project stakeholders must understand. These executable requirements are a corner stone of a process commonly called Acceptance Test Driven Development (ATDD) or Specification by Example.
One way to write these requirements/tests is Given-When-Then style popularized by Behavior Driven Development (BDD). When writing test cases in this style, the initial state is usually expressed with a keyword starting with word Given, the actions are described with keyword starting with When and the expectations with a keyword starting with Then. Keyword starting with And or But may be used if a step has more than one action.
*** Test Cases ***
Valid Login
Given login page is open
When valid username and password are inserted
and credentials are submitted
Then welcome page should be openДавно занимаюсь этой темой.
Можно ещё автоматически создавать по тестам (пример фичи на Gherkin tinyurl.com/y5grnph8) видеоинструкции (пример видео tinyurl.com/y3tqqh7d) или текстовой инструкции с анимацией (пример текстовой инструкции tinyurl.com/y4dn9btx).
Да, посмотрел ссылки — здорово!
У SAP-а есть свои инструменты для создания инструкций (название могу перепутать, поэтому опущу), они даже интегрированы с автотестами (но только eCATT, если не ошибаюсь). Но хотелось большего (в плане модульности), и более простого.
У нас эта часть находится в развитии — то, что сделано, еще не финал...
библиотека управления SAP-ом написана на python (там немного — пара сотен строк)
А это ваша рукописная библиотека или где-то нашли?
И вопрос в целом: есть ли какие-то адекватные инструменты для скрещивания Python и SAP?
Библиотека рукописная — кто же напишет код в формате Robot Remote Server??? Я посматривал интернет и пару раз писал в Robot Framework сообщество про то, что мы используем робот для автоматического тестирования SAP, что-то никто не заинтересовался… Мы есть в списке клиентов робота на их сайте, впочем. Этого я добился (и даже — в первом ряду, но это — алфавит так лег, я думаю).
Библиотека базируется на документированном SAP-ом протоколе взаимодействия с SAP GUI (название документа я привел — он существует, проверил перед публикацией).
Вопрос про "скрещивание" слишком открытый (=широкий): SAP допускает исполнение python-кода (где-то в дебрях ABAP, т.е. можно писать на python-е вместо ABAP-а), мы смотрели — не поняли, зачем нам это нужно (точно ограничений и граблей много разложено...). Эту тему лучше погуглить, но в-целом, насколько мы поняли, пересечений python-а и SAP ERP нет и не планируется.
Вроде как, SAP поддерживает все "открытые" инструменты в части ML (в своей BigData платформе), там должен быть python, но это — другая область...
Робот тестирует SAP ERP