Мы в Альфастраховании используем 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 (не какие-то "костыли").
Архитектура
(да позволено мне будет употребить здесь это слово)
Как все работает:
- скрипт выполняется на сервере (слово "сервер" здесь употребил в том смысле, что этот компьютер обслуживает наши запросы на тестирование. В данном конкретном случае правильнее использовать слово "клиент", потому что именно скрипт управляет процессом тестирования)
- посредством стандартного для робота механизма Remote скрипт взаимодействует с серверной компонентой робота, работающей на SUT (system under test)
- эта серверная компонента вызывает методы библиотеки управления SAP-ом
- SAP GUI отрабатывает эти запросы (в синхронном режиме, это важно)
- результаты выполнения запросов или просто "отбивки" возвращаются в скрипт на "сервер", где используются в процессе тестирования
Технически
- "сервер" — это виртуалка под Ubuntu
- SUT — рабочее место, на котором установлено и настроено рабочее место SAP (в нашем случае это — Windows компьютер или виртуалка)
- библиотека управления SAP-ом написана на python (там немного — пара сотен строк)
- "скрипт" — это "программа" на языке, понятном Robot Framework
- робот (как таковой) подразумевает командную строку, поскольку разработчики на ABAP к такому не привыкли, я сделал WEB интерфейс, обеспечивающий, в-частности, коллективную работу (о нем чуть ниже).
Что же замечательного
Собственно что же такого мы получили, кроме отсутствия лицензионного обременения?
Много чего, если кратко и о главном:
Русский язык
Скрипт выглядит примерно так:
В самом начале пути (наверное, во время пилота) я подумал — а что мы будем ломать язык и придумывать какие-то непонятные-даже-нам-самим слова? Робот подразумевает создание собственных ключевых слов (пардон за терминологию — у него это так называется). Так почему бы нам их не придумывать сразу на русском языке? Спросил в сообществе тестировщиков (где-то в недрах интернета) — меня "зашикали": опасно, зачем, кто сказал и т.п. Я таки пошел своим путем — у нас все по-русски (переменные, слова, остаются только управляющие конструкции робота, но их надо прятать внутрь ключевых слов — если видишь английский, значит пора рефакторить).
Чем хорош русский язык (кроме понятности без словаря) — скрипт можно показать "не айтишнику", бизнес человеку. Можно прямо с ним этот скрипт и писать (не буду здесь даже пытаться уйти в тему ATDD — это отдельный и большой пост, когда-нибудь напишу).
Полный и тотальный контроль и расширяемость
Я точно знаю, что происходит в процессе тестирования. Нет вообще никакой магии — все предельно понятно. Не знаю, как кому, мне такое нравится.
Про расширяемость — функциональность можно развивать в любую сторону, чем мы активно пользовались:
- получилось придумать собственный "язык" тестовых скриптов, понятный бизнесу
- удалось автоматически проверять — корректно ли по окончании теста заполнены поля в интерфейсе (для этого, в-частности, разделили переменные робота на параметры запуска и параметры интерфейса, сделали возможным определить — в каком интерфейсном элементе должен оказаться какой параметр запуска)
- в тесты можно добавить точки останова, во время останова — посмотреть значения переменных
- реализовали механизм формирования шаблонов файлов и их "подкладывания" в процесс исполнения — без этого тестирование такого зверя как ПВУ было бы невозможно (а мы его тестировали в полностью автоматическом режиме — от формирования заявки до разбора выписки)
Наличие собственного веб интерфейса добавило еще возможностей по расширению — например, мы можем позволить себе видоизменить язык робота (придумали, к примеру, свой условный оператор — не нравился нам и нашим бизнес пользователям стандартный "Run keyword if"). Это стало возможно потому, что файлы с исходным кодом тестов генерируются для робота веб приложением.
Легкость входа
Как правило, тестировщики не обладают познаниями в SAP инфраструктуре и, тем более, SAP программировании. Освоить робота и наши к нему доработки у них получается за пару недель.
Инструкции пользователя
Замахнулись мы и на "Вилиама нашего..." — на документацию. Ни для кого не секрет — документации на систему как правило нет, а даже если и есть, то она очень быстро устаревает. Пользователи передают правила работы с системой "из уст в уста". Если код автоматического теста — это описание того, как нужно по мнению автора использовать систему, то почему бы это не преобразовать в инструкцию?
Конечно, на этом фрагменте плохо видно детали, важно, что инструкция формируется и обновляется в полностью автоматическом режиме, включая скриншоты. Инструкция всегда актуальна (ибо автотесты всегда работают). В случае 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:
- владелец продукта по окончании этапа бизнес тестирования утверждает транспортные запросы к переносу
- утвержденные запросы "переезжают" по одному в предпродуктивную среду, где в соответствии с настройками запускается тот или иной набор тестов (точнее — проектов)
- если результат работы тестов положительный, запрос деблокируется и "едет" в продуктивную среду
- при возникновении ошибок автору запроса отправляется письмо со ссылкой на отчет о тестировании (сформированный роботом), запрос дальше не "едет"
Важно — веб интефейс существенно снижает порог входа в процесс тестирования: запустить тест просто — нажать кнопку "старт". При этом (за счет использования Robot Framework) сохраняются все преимущества файлового представления тестов (управление версиями, командная строка и связанная с ней автоматизация и т.п.).
Не SAP-ом единым
Мы успешно применяли нашу разработку для тестирования не только SAP GUI, была у меня небольшая разработка (упрощенный интерфейс регистрации убытка) на python и django. Поскольку все базовые моменты у нас уже были реализованы, все, что потребовалось сделать — написать библиотеку управления браузером (такую же, как была у меня для управления SAP GUI, только через Selenium). И получилось замечательно:
- тесты по-прежнему работают на линуксовой виртуалке (на той же самой — в одном "инстансе" живут тесты SAP и не SAP-а)
- браузер "мигает" на рабочем месте тестировщика (полный визуальный контроль без всяких ухищрений)
- стандартные отчеты, привычный инструментарий
В тестах этой системы я пошел дальше (в сторону ATDD) — визуально видимые элементы (метки и placeholder-ы) формировались пероначально в тестах, там согласовывались с бизнесом и уже оттуда "попадали" в исходный код самой системы (получилось немного DRY) — нельзя написать код, не написав сначала тест. Круто?
Конечно, для веб приложений разработано много инструментария, но не могу сказать, что я испытывал какие-то неудобства в процессе работы. Получилось и тут хорошо...
Подытоживая
Мир SAP велик и содержит, казалось бы, все необходимое для полного счастья разработчиков. Но это совсем не значит, что надо ходить только по тем дорожкам, которые "проторил" SAP и его экосистема. Полезно в начале пути надо задать себе вопрос: а я точно хочу делать "как все"? Мы в Альфастраховании его себе задаем и не только в IT.
И, еще раз, в программировании все возможно, вопрос только времени и денег (мотивации).