Робот тестирует SAP ERP

    Мы в Альфастраховании используем SAP ERP как процессную систему урегулирования убытков. И так уж получилось, что мы ее немножко дорабатываем, это неизбежно приводит к возникновению в коде ошибок. Если ошибки доходят до продуктивной системы — это плохо. Этого надо избегать, один из способов — регрессионное тестирование. В этой статье я расскажу о том, как именно мы проводим "регресс" для SAP, потому что делаем мы это (эх!) нестандартно.


    Началось все это несколько лет назад. В те годы мы уже активно использовали регрессионное тестирование, но никак не могли сделать этого в SAP — используемые инструменты с SAP-ом не работали, изучать "заточенные" под SAP инструменты команда тестировщиков что-то не хотела. Уже точно и не вспомню почему, но я воспринял это как вызов (это было еще до того, как я переключился на дата инженерию) и решил "изучить" вопрос.


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


    Крупными мазками


    Есть опасность уйти в детали и потерять читателей, попробую этого не сделать (как автор, я знаю все детали).


    Началось все с изучения, общения с SAP, нашими партнерами и мистером Гуглом.


    Итог этого общения получился такой:


    • у SAP есть инструменты для автоматизации тестирования (мы смотрели eCATT, пристально SAP CBTA)
    • они требуют существенного погружения (особенно SAP CBTA)
    • возможны ограничения при необходимости выйти за пределы SAP (он же не в "вакууме" у нас живет)
    • есть продукты третьих фирм (например, HP), но у нас по ним компетенции нет, точно также как и купленных лицензий
    • существует способ "управления" SAP-ом снаружи (эту идею мне подсказала компания Конвиста, спасибо большое ей за это)

    Поскольку лично я знаниями по SAP не обладал, то решил попробовать покопать в последнем направлении — управлении SAP-ом не из SAP-а. Достаточно быстро мистер Гугл предоставил документ "SAP GUI Scripting API for the Windows and Java Platforms", что послужило отличным стартом это инициативы. Быстрый тест на любимом python показал — работает.


    Далее дело было за малым — найти подходящий фреймворк для автоматизации тестирования. Поскольку любимым языком был python, то в рассмотрение достаточно быстро попал Robot Framework. А, собственно, после того, как попал в список и был испробован, то только он в списке и остался. Подкупило то, что "оно" сразу заработало (забегая вперед — и до сих пор работает, ни минуты не жалею о сделанном выборе).


    Небольшой пилот показал — SAP совершенно замечательно "управляется" роботом (буду называть Robot Framework таким русским словом): быстро, синхронно, предсказуемо и надежно. При этом — подчеркну — мы используем документированный SAP-ом способ взаимодействия с SAP GUI (не какие-то "костыли").


    Архитектура


    (да позволено мне будет употребить здесь это слово)


    image


    Как все работает:


    • скрипт выполняется на сервере (слово "сервер" здесь употребил в том смысле, что этот компьютер обслуживает наши запросы на тестирование. В данном конкретном случае правильнее использовать слово "клиент", потому что именно скрипт управляет процессом тестирования)
    • посредством стандартного для робота механизма Remote скрипт взаимодействует с серверной компонентой робота, работающей на SUT (system under test)
    • эта серверная компонента вызывает методы библиотеки управления SAP-ом
    • SAP GUI отрабатывает эти запросы (в синхронном режиме, это важно)
    • результаты выполнения запросов или просто "отбивки" возвращаются в скрипт на "сервер", где используются в процессе тестирования

    Технически


    • "сервер" — это виртуалка под Ubuntu
    • SUT — рабочее место, на котором установлено и настроено рабочее место SAP (в нашем случае это — Windows компьютер или виртуалка)
    • библиотека управления SAP-ом написана на python (там немного — пара сотен строк)
    • "скрипт" — это "программа" на языке, понятном Robot Framework
    • робот (как таковой) подразумевает командную строку, поскольку разработчики на ABAP к такому не привыкли, я сделал WEB интерфейс, обеспечивающий, в-частности, коллективную работу (о нем чуть ниже).

    Что же замечательного


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


    Много чего, если кратко и о главном:


    Русский язык


    Скрипт выглядит примерно так:


    image


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


    Чем хорош русский язык (кроме понятности без словаря) — скрипт можно показать "не айтишнику", бизнес человеку. Можно прямо с ним этот скрипт и писать (не буду здесь даже пытаться уйти в тему ATDD — это отдельный и большой пост, когда-нибудь напишу).


    image


    Полный и тотальный контроль и расширяемость


    Я точно знаю, что происходит в процессе тестирования. Нет вообще никакой магии — все предельно понятно. Не знаю, как кому, мне такое нравится.


    Про расширяемость — функциональность можно развивать в любую сторону, чем мы активно пользовались:


    • получилось придумать собственный "язык" тестовых скриптов, понятный бизнесу
    • удалось автоматически проверять — корректно ли по окончании теста заполнены поля в интерфейсе (для этого, в-частности, разделили переменные робота на параметры запуска и параметры интерфейса, сделали возможным определить — в каком интерфейсном элементе должен оказаться какой параметр запуска)
    • в тесты можно добавить точки останова, во время останова — посмотреть значения переменных
    • реализовали механизм формирования шаблонов файлов и их "подкладывания" в процесс исполнения — без этого тестирование такого зверя как ПВУ было бы невозможно (а мы его тестировали в полностью автоматическом режиме — от формирования заявки до разбора выписки)

    Наличие собственного веб интерфейса добавило еще возможностей по расширению — например, мы можем позволить себе видоизменить язык робота (придумали, к примеру, свой условный оператор — не нравился нам и нашим бизнес пользователям стандартный "Run keyword if"). Это стало возможно потому, что файлы с исходным кодом тестов генерируются для робота веб приложением.


    Легкость входа


    Как правило, тестировщики не обладают познаниями в SAP инфраструктуре и, тем более, SAP программировании. Освоить робота и наши к нему доработки у них получается за пару недель.


    image


    Инструкции пользователя


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


    image


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


    Инструкции мы форматировали посредством Sphinx-а (я уверен, многие узнали цветовую гамму), поэтому они доступны и как онлайн руководство, так и в печатном виде.


    Немного про Robot Framework


    Все же нельзя совсем ничего не сказать про робота — получится слишком непонятно и поверхностно. Постараюсь кратко.


    Основная идея этого фреймворка — возможность создания собственного языка тестирования (в терминологии робота исполняемой единицей является keyword — ключевое слово). Фреймворк предоставляет


    • среду исполнения программ (программисты — не обижайтесь) на этом языке
    • функционально богатые библиотеки (от работы со строками и списками, до ssh и selenium-а)
    • отчетность (в процессе использования не возникло даже мысли писать какого бы то ни было отчета)
    • простую парадигму формирования программы из ключевых слов (немного своеобразная, но к ней можно привыкнуть), есть такие вещи как переменные, параметры и результаты "вызовов" (ключевых слов)
    • простую и мощную расширяемость — очень просто создать свою библиотеку на python (мы, например, таким образом работали с Excel-ем), как локальную (т.е. исполняемую там же, где и код теста), так и удаленную (например ту, которая управляет SAP GUI)

    Процесс создания теста достаточно прямолинеен


    • формируем последовательность действий и переводим ее в термины робота (чуть ниже будет конкретика про взаимодействие с тестируемой системой)
    • повторяющиеся последовательности рефакторим в свои (новые) ключевые слова
    • запускаем тест, смотрим — как работает, исправляем, улучшаем
    • отладка обеспечивается точками останова (с возможностью просмотра переменных — обеспечивается архитектурой, точнее — использование remote библиотеки робота)

    В результате получается даже не программы (см. примеры выше), а скорее формализованная последовательность действий, которая, кстати, описывает использование программы в том виде, каке это задумал автор (см. ATDD выше).


    Взаимодействие с тестируемой системой


    В нашем случае мы тестируем на уровне интерфейса пользователя (т.е. наши тесты взаимодействуют с SAP-ом на уровне GUI — "нажимают" кнопки, заполняют текстовые поля и т.п.). Общепризнанно, что такой способ написания тестов не является самым лучшим. Я с этим отчасти согласен, но готов послушать и пообсуждать — как же лучше тестировать SAP GUI приложения (типа нашего SAP FS CM).


    Есть такой гуру — Роберт Мартин (он же "uncle Bob" — автор "Clean coder", если кто читал), мы с ним по этому поводу немного попереписывались. Сошлись на том, что если это не очень сложно делать, это не очень часто меняется (ломая тесты), то и ладно — можно тестировать и через интерфейс.


    Со своей стороны могу сказать так: в случае SAP GUI существует не так много вариантов реализации интерфеса пользователя. Если нужно добавить возможность, к примеру, отслеживать IMEI код, то сделать это можно практически одним способом — добавив соответствующее поле на одну из закладок. Так вот я считаю, что все нюансы этого "добавления" может и должен продумать заказчик (как это поле будет называться в интерфейсе, ширина, порядок использования и т.п.). И он может сделать это непосредственно в скрипте, который будет потом это автоматически тестировать. Если продумать доработку до конца не получается (как говорят — ну вы сделайте, а мы посмотрим), то лучше этой доработкой и не заниматься. А сделать то, что получается продумать. Ну это я опять в ATDD полез...


    Возвращаясь к взаимодействию с SAP GUI: у нас получилось, как я уже писал, порядка 200 строк на python и порядка 10 разных функций управления интерфейсом (типа "перейти на закладку", "заполнить поле", "нажать кнопку"). Этот набор сформировался практически в первые дни и впоследствии не сильно расширялся. К чести SAP отмечу, что работает все очень быстро — глаз не успевает уследить за тем, как "мигает" интерфейс, для замедления в цикл управления вставляли задержки (в случаях необходимости визуального контроля). Также отмечу плюсы синхронной работы — нигде в коде не приходится ничего ждать, если, к примеру, кнопка нажалась, то соответствующее нажатию кнопки действие завершилось (например, убыток сохранен).


        def get_ctrl_attr ( self, uid, attr ):
            """ Читает значение атрибута контрола (по имени атрибута)
            Возвращает текст (в случае успеха) 
            или exception = ошибка (текст ошибки для log)
            """
            ctrl = self._get_ctrl(uid)
    
            try:
                retText = getattr( ctrl, attr )
            except:
                raise AssertionError("У контрола {1} нет атрибута {0}".decode("utf-8").format(attr,uid))
    
            return retText

    Чуть комментариев к коду


    • приведен фрагмент библиотеки управления SAP GUI
    • библиотека — это объект, методы напрямую доступны в тестах (в ключевых словах), например, приведенный выше метод можно вызвать так: "res = get ctrl attr ${UID} text" (использую нотацию робота)
    • в случае ошибки текст exception-а будет виден в логе робота (для этого ничего делать не надо — только "зарейзить" exception

    Код получается очень простым, это радует.


    Запуск тестов


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


    • владелец продукта по окончании этапа бизнес тестирования утверждает транспортные запросы к переносу
    • утвержденные запросы "переезжают" по одному в предпродуктивную среду, где в соответствии с настройками запускается тот или иной набор тестов (точнее — проектов)
    • если результат работы тестов положительный, запрос деблокируется и "едет" в продуктивную среду
    • при возникновении ошибок автору запроса отправляется письмо со ссылкой на отчет о тестировании (сформированный роботом), запрос дальше не "едет"

    image


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


    Не SAP-ом единым


    Мы успешно применяли нашу разработку для тестирования не только SAP GUI, была у меня небольшая разработка (упрощенный интерфейс регистрации убытка) на python и django. Поскольку все базовые моменты у нас уже были реализованы, все, что потребовалось сделать — написать библиотеку управления браузером (такую же, как была у меня для управления SAP GUI, только через Selenium). И получилось замечательно:


    • тесты по-прежнему работают на линуксовой виртуалке (на той же самой — в одном "инстансе" живут тесты SAP и не SAP-а)
    • браузер "мигает" на рабочем месте тестировщика (полный визуальный контроль без всяких ухищрений)
    • стандартные отчеты, привычный инструментарий

    В тестах этой системы я пошел дальше (в сторону ATDD) — визуально видимые элементы (метки и placeholder-ы) формировались пероначально в тестах, там согласовывались с бизнесом и уже оттуда "попадали" в исходный код самой системы (получилось немного DRY) — нельзя написать код, не написав сначала тест. Круто?


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


    Подытоживая


    Мир SAP велик и содержит, казалось бы, все необходимое для полного счастья разработчиков. Но это совсем не значит, что надо ходить только по тем дорожкам, которые "проторил" SAP и его экосистема. Полезно в начале пути надо задать себе вопрос: а я точно хочу делать "как все"? Мы в Альфастраховании его себе задаем и не только в IT.


    И, еще раз, в программировании все возможно, вопрос только времени и денег (мотивации).

    АльфаСтрахование
    29,54
    Компания
    Поделиться публикацией

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

      0
      Не хватает ссылки на github с примерами.
      А по выбору инструмента интересует, почему не рассматривали CBTA, почему не подошёл eCATT, и смотрели ли вообще UFT или TestComplete?
        0
        Ссылки на github с примерами пока нет, примеры чего именно Вам интересны? GitHub — это исходники на языках программирования (как правило), если туда выложить тесты на нашем языке (робота) — вряд ли это интересно. Если речь идет о библиотеке управления SAP GUI, то да, ее выложу (надо немного «причесать»).

        Про инструменты:

        CBTA — мой косяк (опечатка, исправил), я вместо него написал TAO…

        eCATT: это все же программирование (своего рода) на ABAP, не хотел туда углубляться (и «углублять» наших тестировщиков). Представьте сложные случаи — в нашем случае убыток по ПВУ создается руками примерно за 10 минут, уложить это в «портянку» на eCATT — вряд ли. Нужно будет что-то конструировать, что мы и сделали (вне SAP).

        TestComplete (насколько я помню — уже года 4 прошло от начала) на тот момент не мог управлять SAP GUI напрямую, именно он использовался нашими тестировщиками для регресса всего остального нашего софта, и именно в нем они никак не могли тогда научиться тестировать SAP.

        UFT и много другое смотрели «по диагонали» — в гугловой выдаче с минимальным погружением. Я искал простой, максимально универсальный и SAP-онезависимый способ. В процессе поиска мне показали, как из Excel-а заполняют документы (партнер SAP в каком-то из проектов для просто автоматизации рутинной операции), видя это желание осваивать какой-то лицензионно обременный продукт автоматизированного тестирования отошло на второй план.
          0
          По коммерческим решениям типа UFT и TestComplete понял (второй сейчас умеет в SAP, но несколько кривовато, на мой взгляд). С eCATT'ом тоже согласен, немного монструозный инструмент.
          А можете поделиться мнением и впечатлениями о CBTA? Очень актуально для меня сейчас… В плане лицензирования он идёт вместе с SolMan'ом, так что проблем нет, интересует именно ваш опыт…

          В части GitHub — да, интересуют исходники библиотеки, было бы классно :)
            0
            Про GitHub — понял.

            Про CBTA — я ходил на однодневный семинар в SAP, внимательно слушал и вникал. Поймите меня правильно — давно это было, вот что осталось в памяти:

            Свой большой мир. Чтобы начать тестировать (условно — создать убыток) нужно этот мир освоить и настроить под свою специфику. Это проходимо, но (мой случай) опыта в SAP было мало, для меня это был минус.

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

            Представьте себе: как Вы будете обсуждать с бизнесом сценарий использования планируемой доработки в случае использования CBTA? Я, конечно, в ATDD полез, но эта мысль/цель тогда тоже была. В случае робота мы прямо из ВЕБ интерфейса печатаем текст и идем обсуждать, «крыжить» по бумажке. А потом наращиваем этот текст реальным «мясом»…
        0
        Вы прямо изобрели свой Gherkin.
        Кстати, Gherkin не рассматривали как аналог языка скриптов?
          0

          Нет, не изобретали. Да, рассматривали…


          Робот ориентирован на 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
          0
          Порадовало создание автоматизированных инструкций со скриншотами.
          Давно занимаюсь этой темой.
          Можно ещё автоматически создавать по тестам (пример фичи на Gherkin tinyurl.com/y5grnph8) видеоинструкции (пример видео tinyurl.com/y3tqqh7d) или текстовой инструкции с анимацией (пример текстовой инструкции tinyurl.com/y4dn9btx).
            0

            Да, посмотрел ссылки — здорово!


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


            У нас эта часть находится в развитии — то, что сделано, еще не финал...

            0
            библиотека управления SAP-ом написана на python (там немного — пара сотен строк)

            А это ваша рукописная библиотека или где-то нашли?
            И вопрос в целом: есть ли какие-то адекватные инструменты для скрещивания Python и SAP?
              0

              Библиотека рукописная — кто же напишет код в формате Robot Remote Server??? Я посматривал интернет и пару раз писал в Robot Framework сообщество про то, что мы используем робот для автоматического тестирования SAP, что-то никто не заинтересовался… Мы есть в списке клиентов робота на их сайте, впочем. Этого я добился (и даже — в первом ряду, но это — алфавит так лег, я думаю).


              Библиотека базируется на документированном SAP-ом протоколе взаимодействия с SAP GUI (название документа я привел — он существует, проверил перед публикацией).


              Вопрос про "скрещивание" слишком открытый (=широкий): SAP допускает исполнение python-кода (где-то в дебрях ABAP, т.е. можно писать на python-е вместо ABAP-а), мы смотрели — не поняли, зачем нам это нужно (точно ограничений и граблей много разложено...). Эту тему лучше погуглить, но в-целом, насколько мы поняли, пересечений python-а и SAP ERP нет и не планируется.


              Вроде как, SAP поддерживает все "открытые" инструменты в части ML (в своей BigData платформе), там должен быть python, но это — другая область...

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое