Оглавление

Нестандартный регресс для SAP. Это как?

Мой подход к проблеме

Архитектура процесса

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

Технические компоненты

Что же замечательного в результате?

Русский язык

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

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

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

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

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

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

Не  единым хлебом SAP

Подытоживая

Нестандартный регресс для SAP. Это как?

Компания «АльфаСтрахование» использует 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 (не какие-то "костыли").

Архитектура процесса

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

Рис.1. Архитектура процесса

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

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

Технические компоненты

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

Что же замечательного в результате?

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

Русский язык

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

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

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

Пример скрипта:

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

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

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

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

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

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

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

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

Замахнулись мы и на "Вилиама нашего..." — на документацию. Ни для кого не секрет