Sap cbta что это
Автоматизированное тестирование SAP: опыт «Апланы»
Наши инженеры считают, что инструменты тестирования SAP должны быть доступными, удобными, стабильными, простым в освоении для тестировщиков, а главное — легко встраиваемыми в любой процесс. Выбор инструментов обязательно должен учитывать пожелания заказчика и особенности его IT-ландшафта.
ERP-системы, вроде SAP, могут объединять подразделения компании, обеспечивая автоматизацию планирования, учета и анализа всех бизнес-процессов. Они обрабатывают большие массивы данных, поэтому часто подвергаются перегрузкам, а с выходом обновлений в них могут появляться ошибки, сбиваться настройки и т.д. С целью выявления проблем в работоспособности SAP и его модулей проводится тестирование.
Автоматизированное тестирование SAP
В прошлой статье мы уже писали, что в основном для функционального тестирования SAP используются ручные тесты, однако, в сложных ситуациях, на крупных и долгосрочных проектах выгоднее использовать автоматизированные тесты. Если тестовая модель постоянно растет, наступает момент, когда ее ручное прохождение начинает обходиться заказчику дорого и занимает много времени. С помощью автоматизации тестирования можно без потери качества протестировать тот же объем, но быстрее и за меньшую стоимость. Ее успех обеспечивается правильным выбором инструмента тестирования и инфраструктуры автоматизации.
Процесс автоматизации тестирования состоит из следующих этапов:
Для автоматизированного тестирования SAP используют такие решения, как SAP CBTA, SAP ECATT, Unified Functional Testing (UFT), IBM Rational Functional Tester, SmartBear TestComplete и другие. Все перечисленные инструменты сотрудники «IBS AppLine» успешно используют в своих проектах, а если их возможностей становится недостаточно, разрабатывают собственные расширения.
В этом материале мы расскажем о средствах автоматизации SAP-систем, которые наши инженеры по тестированию используют чаще всего.
SAP CBTA (Component-based Test Automation)
Наиболее популярным инструментом для автоматизации тестирования SAP-приложений является SAP CBTA. SAP CBTA – это компонентно-основанный или компонентно-ориентированный инструмент автоматизации тестирования, интегрированный в SAP Solution Manager, и предназначенный для автоматизации E2E тестирования.
Создание автоматизированных тестов происходит с помощью мастера записи действий бизнес-пользователя (Record & Playback). Благодаря этому, инженеру-тестировщику не требуется знания языков программирования.
Особенности и возможности CBTA:
Технические ограничения CBTA:
В автоматизации SAP большинство элементарных операций покрывается поставляемыми компонентами, но бывают ситуации, когда этого мало. Расширить функциональность CBTA можно путем написания собственных библиотек на языке программирования VBScript.
Автоматизированные тесты, написанные на CBTA, могут быть легко интегрированы в методологию CI/CD (Continuous Integration и Continuous Delivery). Запуск автоматизированных тестов производится с помощью встроенного в SAP Solution Manager планировщика, а составление тестового покрытия – с помощью встроенных инструментов SAP BPCA (Business Process Change Analyzer) и SAP TBOM (Technical Bill of Material). SAP BPCA и SAP TBOM анализируют влияние переносимых изменений на бизнес-процессы. Изменения сравниваются со списком объектов еще неизмененной системы (функциональные модули, таблицы, элементы пользовательского интерфейса и т.д.), на основании полученной информации автоматически составляется список автоматизированных тестов для выполнения.
Unified Functional Testing (UFT)
UFT — один из ведущих инструментов автоматизации функционального тестирования, флагманский продукт компании MicroFocus в своей линейке. Использует VBScript (в новых версиях поддерживаются и другие), есть репозиторий объектов и средство хранения данных, возможна интеграция с ALM (хранятся все артефакты тестирования, сами тесты, библиотеки, заведенные дефекты и пр.), поддерживаются многие технологии — не только SAP, но и другие. Основным минусом UFT является стоимость лицензий и отсутствие интеграции с SAP Solution Manager.
Автоматизация SAP с помощью Java
Для автоматизации тестирования SAP можно использовать язык программирования Java и Java-библиотеку Jacob. Среди плюсов — возможность разработать более гибкий фреймворк для автоматизации и применить популярный подход BDD (behavior-driven development). Инструмент Selenium отлично подойдет для тестирования интеграций и веб-порталов SAP. Минусами подхода являются повышенные требования к квалификации команды тестировщиков, увеличенное время разработки автоматизированных тестов по сравнению с инструментами Record & Playback и отсутствие интеграции с SAP Solution Manager.
Сравнительная таблица инструментов
Если не планируется разработка большого количества тестов, то можно воспользоваться инструментами записи действий SAP Scripting Tracker
Благодарим за помощь в подготовке материала заместителя руководителя направления тестирования — Николая Стрельцова, а также старших инженеров-тестировщиков «IBS AppLine» — Владислава Чижова и Никиту Потапова.
All about CBTA- How to create Test scripts, SDC and TCE; How test script runs.
In this blog, I wanted to share some knowledge on CBTA.
CBTA (Component Based Test Automation) is a functionality of SAP Solution Manager where we can create test cases in modular structure. As the name suggests,CBTA is component based testing and there are 2 types of components namely,
1. Screen Components
2. Default Components
Screen components are nothing but the activity done while testing the system under test such as mouse click, entering transactions etc. Default components are the data entered at the time of recording such as values.
Some terminologies to be known are,
1. SUT (System Under Test):
SUT is the managed system which is to be tested. In SUT Management, the following details are maintained
2. SDC (System Data Container)
SDC defines the systems on which the automated test cases are recorded or executed. A system is defined as follows
3. TDC (Test Data Container)
TDC is a central repository for all test data. It contains the information of parameters, attributes and variants.
Now we will look how test scripts, SDC are created and see how automated testing is done with the help of SAP Solution Manager
Prerequisites:
Perform system configuration steps as given in the guided procedure SOLMAN_SETUP prior to create test script
Note: Test cases can be created in configuration phase of each project via SOLAR02 transaction. But I am explaining how CBTA works via transaction SM_WORKCENTER
Step 1: Login into SAP Solution Manager system and run transaction SM_WORKCENTER. Under Test Management workcenter, click Easy Test Automation as shown below
Step 2: A pop up opens where you can create new SDC or use existing SDC. To create new SDC, select System Data and enter the SDC name and click create as shown below
Step 3: Then you will be directed to SDC creation window where we need to give the name of the System Data Container and specify the logical component, target system as shown in the below screenshots.
After entering the details, upon saving the SDC contains the following information
Save these configuration in transport request.
Step 4: Now, in Test Management workcenter, go to CBTA Settings-> Maintain SUT. Here, you need to import the SDC created as shown below
Step 5: After selecting and importing the SDC, now you need to specify the RFC that communicates with the SUT which is configured as prerequisite and also assign the tester profile so that it enables logon to managed system while the script runs.
Step 6: Now, to create Test scripts, in Test Management workcenter-> Test Repository-> Test Scripts
When you click create Test Scripts, a pop up will appear where you need to give the name and title of the script, test tool would be CBTA as shown below
Step 7: Now, in the attributes tab of the test script, you need to specify the Application Component, here it will be CBTA component, SDC for this test script, Target system, Executable type and the Transaction as shown below
Note: Executable can be a transaction, BSP Application, CRM Webclient, Webdynpro application
Step 8: Once the details are filled in step 7, now click Launch button as that the script runs in the managed system remotely.
Note: In order to run the scripts remotely, settings in the managed system should be done. For this, run transaction SCC4 in corresponding managed system and keep the settings as changes are allowed.
Also you must enable scripts to run by making the changes in SAP Logon settings are shown below
So finally when you click on Launch CBTA, the scripts runs in the SUT and the test log is stored in SAP Solution Manager system.
Робот тестирует SAP ERP
Мы в Альфастраховании используем SAP ERP как процессную систему урегулирования убытков. И так уж получилось, что мы ее немножко дорабатываем, это неизбежно приводит к возникновению в коде ошибок. Если ошибки доходят до продуктивной системы — это плохо. Этого надо избегать, один из способов — регрессионное тестирование. В этой статье я расскажу о том, как именно мы проводим «регресс» для SAP, потому что делаем мы это (эх!) нестандартно.
Началось все это несколько лет назад. В те годы мы уже активно использовали регрессионное тестирование, но никак не могли сделать этого в SAP — используемые инструменты с SAP-ом не работали, изучать «заточенные» под SAP инструменты команда тестировщиков что-то не хотела. Уже точно и не вспомню почему, но я воспринял это как вызов (это было еще до того, как я переключился на дата инженерию) и решил «изучить» вопрос.
Результаты изучения (а также «делания») — в этой статье (ниже), кратко скажу так: мы автоматически тестируем SAP (и его ближайшее окружение), делаем это достаточно эффективно (во всех смыслах), мы не потратили ни рубля на лицензии и обучение, наш подход прост и вполне воспроизводим. И мы не используем никакие инструменты SAP для автоматического тестирования SAP (разве что в том месте, где мы встроились в его транспортную систему).
Крупными мазками
Есть опасность уйти в детали и потерять читателей, попробую этого не сделать (как автор, я знаю все детали).
Началось все с изучения, общения с SAP, нашими партнерами и мистером Гуглом.
Итог этого общения получился такой:
Поскольку лично я знаниями по SAP не обладал, то решил попробовать покопать в последнем направлении — управлении SAP-ом не из SAP-а. Достаточно быстро мистер Гугл предоставил документ «SAP GUI Scripting API for the Windows and Java Platforms», что послужило отличным стартом это инициативы. Быстрый тест на любимом python показал — работает.
Далее дело было за малым — найти подходящий фреймворк для автоматизации тестирования. Поскольку любимым языком был python, то в рассмотрение достаточно быстро попал Robot Framework. А, собственно, после того, как попал в список и был испробован, то только он в списке и остался. Подкупило то, что «оно» сразу заработало (забегая вперед — и до сих пор работает, ни минуты не жалею о сделанном выборе).
Небольшой пилот показал — SAP совершенно замечательно «управляется» роботом (буду называть Robot Framework таким русским словом): быстро, синхронно, предсказуемо и надежно. При этом — подчеркну — мы используем документированный SAP-ом способ взаимодействия с SAP GUI (не какие-то «костыли»).
Архитектура
(да позволено мне будет употребить здесь это слово)
Что же замечательного
Собственно что же такого мы получили, кроме отсутствия лицензионного обременения?
Много чего, если кратко и о главном:
Русский язык
Скрипт выглядит примерно так:
В самом начале пути (наверное, во время пилота) я подумал — а что мы будем ломать язык и придумывать какие-то непонятные-даже-нам-самим слова? Робот подразумевает создание собственных ключевых слов (пардон за терминологию — у него это так называется). Так почему бы нам их не придумывать сразу на русском языке? Спросил в сообществе тестировщиков (где-то в недрах интернета) — меня «зашикали»: опасно, зачем, кто сказал и т.п. Я таки пошел своим путем — у нас все по-русски (переменные, слова, остаются только управляющие конструкции робота, но их надо прятать внутрь ключевых слов — если видишь английский, значит пора рефакторить).
Чем хорош русский язык (кроме понятности без словаря) — скрипт можно показать «не айтишнику», бизнес человеку. Можно прямо с ним этот скрипт и писать (не буду здесь даже пытаться уйти в тему ATDD — это отдельный и большой пост, когда-нибудь напишу).
Полный и тотальный контроль и расширяемость
Я точно знаю, что происходит в процессе тестирования. Нет вообще никакой магии — все предельно понятно. Не знаю, как кому, мне такое нравится.
Про расширяемость — функциональность можно развивать в любую сторону, чем мы активно пользовались:
Наличие собственного веб интерфейса добавило еще возможностей по расширению — например, мы можем позволить себе видоизменить язык робота (придумали, к примеру, свой условный оператор — не нравился нам и нашим бизнес пользователям стандартный «Run keyword if»). Это стало возможно потому, что файлы с исходным кодом тестов генерируются для робота веб приложением.
Легкость входа
Как правило, тестировщики не обладают познаниями в SAP инфраструктуре и, тем более, SAP программировании. Освоить робота и наши к нему доработки у них получается за пару недель.
Инструкции пользователя
Замахнулись мы и на «Вилиама нашего. » — на документацию. Ни для кого не секрет — документации на систему как правило нет, а даже если и есть, то она очень быстро устаревает. Пользователи передают правила работы с системой «из уст в уста». Если код автоматического теста — это описание того, как нужно по мнению автора использовать систему, то почему бы это не преобразовать в инструкцию?
Конечно, на этом фрагменте плохо видно детали, важно, что инструкция формируется и обновляется в полностью автоматическом режиме, включая скриншоты. Инструкция всегда актуальна (ибо автотесты всегда работают). В случае SAP скриншоты вообще хорошо получаются — в SAP-е всегда можно найти элемент интерфейса — прямоугольник, координаты которого будут релевантны текущему месту в коде теста, вот этот (невидимый глазу) контрол и используется как параметр ключевому слову «сделай скриншот» (это слово, естественно, работает только при соответствующем режиме запуска теста — зачем просто так электричество расходовать).
Инструкции мы форматировали посредством Sphinx-а (я уверен, многие узнали цветовую гамму), поэтому они доступны и как онлайн руководство, так и в печатном виде.
Немного про Robot Framework
Все же нельзя совсем ничего не сказать про робота — получится слишком непонятно и поверхностно. Постараюсь кратко.
Основная идея этого фреймворка — возможность создания собственного языка тестирования (в терминологии робота исполняемой единицей является keyword — ключевое слово). Фреймворк предоставляет
Процесс создания теста достаточно прямолинеен
В результате получается даже не программы (см. примеры выше), а скорее формализованная последовательность действий, которая, кстати, описывает использование программы в том виде, каке это задумал автор (см. ATDD выше).
Взаимодействие с тестируемой системой
В нашем случае мы тестируем на уровне интерфейса пользователя (т.е. наши тесты взаимодействуют с SAP-ом на уровне GUI — «нажимают» кнопки, заполняют текстовые поля и т.п.). Общепризнанно, что такой способ написания тестов не является самым лучшим. Я с этим отчасти согласен, но готов послушать и пообсуждать — как же лучше тестировать SAP GUI приложения (типа нашего SAP FS CM).
Есть такой гуру — Роберт Мартин (он же «uncle Bob» — автор «Clean coder», если кто читал), мы с ним по этому поводу немного попереписывались. Сошлись на том, что если это не очень сложно делать, это не очень часто меняется (ломая тесты), то и ладно — можно тестировать и через интерфейс.
Со своей стороны могу сказать так: в случае SAP GUI существует не так много вариантов реализации интерфеса пользователя. Если нужно добавить возможность, к примеру, отслеживать IMEI код, то сделать это можно практически одним способом — добавив соответствующее поле на одну из закладок. Так вот я считаю, что все нюансы этого «добавления» может и должен продумать заказчик (как это поле будет называться в интерфейсе, ширина, порядок использования и т.п.). И он может сделать это непосредственно в скрипте, который будет потом это автоматически тестировать. Если продумать доработку до конца не получается (как говорят — ну вы сделайте, а мы посмотрим), то лучше этой доработкой и не заниматься. А сделать то, что получается продумать. Ну это я опять в ATDD полез.
Возвращаясь к взаимодействию с SAP GUI: у нас получилось, как я уже писал, порядка 200 строк на python и порядка 10 разных функций управления интерфейсом (типа «перейти на закладку», «заполнить поле», «нажать кнопку»). Этот набор сформировался практически в первые дни и впоследствии не сильно расширялся. К чести SAP отмечу, что работает все очень быстро — глаз не успевает уследить за тем, как «мигает» интерфейс, для замедления в цикл управления вставляли задержки (в случаях необходимости визуального контроля). Также отмечу плюсы синхронной работы — нигде в коде не приходится ничего ждать, если, к примеру, кнопка нажалась, то соответствующее нажатию кнопки действие завершилось (например, убыток сохранен).
Чуть комментариев к коду
Код получается очень простым, это радует.
Запуск тестов
Следуя логике робота, индивидуальные тесты у нас объединяются в проекты. Тест или проект можно запустить вручную из веб интерфейса. Также процесс регрессионного тестирования встроен в транспортную систему SAP:
Важно — веб интефейс существенно снижает порог входа в процесс тестирования: запустить тест просто — нажать кнопку «старт». При этом (за счет использования Robot Framework) сохраняются все преимущества файлового представления тестов (управление версиями, командная строка и связанная с ней автоматизация и т.п.).
Не SAP-ом единым
Мы успешно применяли нашу разработку для тестирования не только SAP GUI, была у меня небольшая разработка (упрощенный интерфейс регистрации убытка) на python и django. Поскольку все базовые моменты у нас уже были реализованы, все, что потребовалось сделать — написать библиотеку управления браузером (такую же, как была у меня для управления SAP GUI, только через Selenium). И получилось замечательно:
В тестах этой системы я пошел дальше (в сторону ATDD) — визуально видимые элементы (метки и placeholder-ы) формировались пероначально в тестах, там согласовывались с бизнесом и уже оттуда «попадали» в исходный код самой системы (получилось немного DRY) — нельзя написать код, не написав сначала тест. Круто?
Конечно, для веб приложений разработано много инструментария, но не могу сказать, что я испытывал какие-то неудобства в процессе работы. Получилось и тут хорошо.
Подытоживая
Мир SAP велик и содержит, казалось бы, все необходимое для полного счастья разработчиков. Но это совсем не значит, что надо ходить только по тем дорожкам, которые «проторил» SAP и его экосистема. Полезно в начале пути надо задать себе вопрос: а я точно хочу делать «как все»? Мы в Альфастраховании его себе задаем и не только в IT.
И, еще раз, в программировании все возможно, вопрос только времени и денег (мотивации).
Sap cbta что это
Что пишут в блогах
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
В трансляцию блогов регулярно добавляются новые блоги. Их количество уже давно перевалило за отметку 100. Ну а мы продолжаем знакомить Вас с новыми блогами.
«Аплана» — лидирующий поставщик услуг тестирования и обеспечения качества информационных систем, а также управления жизненным циклом приложений. Компания на рынке уже 17 лет, в штате более 700 специалистов, общее количество проектов превысило 1500.
Теперь мы запустили блог. В нем будут публиковаться экспертные материалы наших специалистов, информационные статьи, новости компании и рынка, аналитика, разбор кейсов и многое другое.
Публикуем одну из первых статей блога.
Оригинальная публикация: http://aplana.ru/infocenter/corpblog/testirovaniesap
Компания SAP — один из лидеров рынка в классе ERP-систем. Как и любое ПО, продукты SAP требуют тестирования. Для выбора подходящих инструментов тестирования нужно разбираться в архитектуре SAP, понимать принципы работы ее многочисленных модулей и нестандартную логику взаимодействия компонентов, а главное — знать обо всех особенностях и ограничениях системы.
Для любой компании, которая планирует оставаться на рынке и удерживать лидирующие позиции, погружение в «цифровой мир» для поиска новых бизнес-возможностей — неизбежно. Внедрение ERP-системы фактически является условием для публичной компании. На рынке представлено большое количество систем для управления бизнес-процессами, однако, крупные компании стабильно выбирают SAP.
Система управления каждой второй российской компании основывается на решениях SAP, а значит — она занимает более половины всего российского рынка, опередив «1С». В 2017 году выручка SAP в России составила 468,4 млн евро, что на 32% больше, чем годом ранее. Эксперты предсказывают дальнейший рост интереса к продуктам вендора, для многих они стали корпоративным стандартом.
Предпосылки для тестирования SAP
Тестирование — важный этап обеспечения качества ПО, направленный на детальное исследование программного кода и выявление ошибок в работе системы. Одна из ее главных целей — проверка соответствия работоспособности системы в целом или отдельных модулей ожиданиям заказчика. Тестирование SAP требуется в трех случаях: когда система только внедряется и нужно снизить возможные риски, когда система установлена, работает, но не без проблем, а также при модификации модулей SAP.
Как правило, пользователи SAP — крупные компании с внушительными оборотами. Потери, которые может понести бизнес в случае неправильной работы ПО, более, чем значительны. Нестабильность в работе SAP-систем, любое нестандартное поведение обязательно отразятся на бизнесе. Цена ошибки в этом случае очень высока: всего один час отказа информационной системы приводит к потерям до 400.000 долларов. Чтобы оценить масштаб возможного ущерба, достаточно представить, что из-за проблем в системе среднестатистического банка с филиалами в 60 городах России происходит задержка в проведении финансовых операций на 30-40 секунд.
Есть и реальные кейсы. Например, в 2003 году компания «Утконос» силами штатных сотрудников и нескольких программистов-фрилансеров внедрила SAP R/3. В системе часто случались сбои: заказы путались и приходили не туда. В 2013 году «Утконос» проводила обновление SAP, но, из-за возникших трудностей, интернет-гипермаркету пришлось на девять дней остановить доставку продуктов. По подсчетам специалистов, такой простой мог привести к потере около 10 млн долларов, не говоря уже о серьезном ударе по репутации. После вынужденного перезапуска потребовалось время, чтобы снова выйти на прежние обороты и вернуть лояльность клиентов.
Своевременное тестирование модулей SAP позволяет оперативно выявить дефекты кода, повысить надежность и отказоустойчивость систем, а значит — избежать финансовых и репутационных потерь.
При работе с SAP важно помнить о нескольких моментах:
Особенности тестирования SAP-систем
1. SAP не user friendly
SAP — одна из лучших систем для автоматизации бизнес-процессов и управления ресурсами предприятия, но у нее не самый понятный интерфейс. В SAP много тонкостей и неочевидных особенностей, в которых трудно разобраться. Чтобы освоить систему, компании приглашают консультантов по SAP или нанимают специалистов по обучению, которые помогают сотрудникам освоить нужный функционал. Без соответствующих навыков, еще в процессе внедрения или настройки SAP, у персонала могут возникнуть сложности, способные привести к задержке в работе целых отделов.
Чтобы помочь своим пользователям, SAP создали бесплатную платформу массовых корпоративных онлайн-курсов openSAP и облачную платформу SAP Learning Hub с доступом ко множеству обучающих материалов и виртуальным учебным комнатам (с бесплатной пробной версией). Для более глубокого погружения можно купить учебный курс по отдельным решениям SAP из каталога SAP Education, а, чтобы улучшить навыки работы с системой или расширить знания в соответствующей области, — пройти сертификацию SAP.Это работает не всегда, ведь в каждой компании и сфере есть специфика.
В большинстве случаев заказчикам нужны свои настройки, а значит и индивидуальный подход к обучению.
2. У SAP сложная архитектура
SAP служит для автоматизации и управления такими внутренними процессами предприятия, как: бухгалтерский учет, торговля, производство, финансы, управление персоналом, управление складами и т. д. Каждый такой внутренний процесс представляется как отдельный модуль. Самые популярные из них: SAP ERP (Enterprise Resource Planning) — планирование ресурсов предприятия, SAP CRM (Customer Relationship Management) — управление взаимоотношениями с клиентами, SAP HCM (Human Capital Management) — управление человеческим капиталом, SAP SRM (Supplier Relationship Management) — управление взаимоотношениями с поставщиками, SAP RE-FX (Flexible Real Estate Management) — управление недвижимостью, SAP EWM (Extended Warehouse Management) — складами и пр. В настоящее время SAP — это более трехсот программных продуктов. Консультанты SAP обычно специализируются на одном-двух модулях, найти тех, кто знает больше, невозможно. Компания SAP предлагает также комплексные решения для всех бизнес-процессов во всех отраслях, например, закупки и сети, привлечение клиентов и коммерция, аналитика, финансы, управление персоналом и другое.
Каждый модуль можно модифицировать под внутренние процессы предприятия и под действующее законодательство стран, в которые поставляется SAP. Такая модификация происходит с помощью языка программирования, которая называется ABAP. Для этих целей нанимают разработчиков и консультантов. Модули SAP содержат в себе функциональные модули, которые вызываются с помощью транзакций. Модификации происходят на уровне функциональных модулей, которые и необходимо тщательно тестировать.
Задача инженеров по тестированию — провести эффективное тестирование программных модификаций любого модуля SAP или целого комплекса вне зависимости от бизнес-специфики, добиться стабильности и быстроты работы системы. Для этого тестировщики должны понимать инфраструктуру полностью: как это работает с точки зрения самой архитектуры SAP (мануальных, административных настроек) и с точки зрения бизнеса.
Интеграция. Еще одна особенность тестирования SAP — неоднородность IT-ландшафта заказчика. Как правило, если в компании есть SAP, то есть и другие системы. В этом случае инженеры тестируют все внешние системы и их интеграцию с SAP. Это могут быть кассы, магазины, pos-терминалы, web-порталы и пр.
Тестирование с нуля. Иногда проектной команде приходится выстраивать процесс тестирования с нуля. Это случается, когда компания работает с SAP, но тестирование не выделено у нее как отдельный процесс — разработчикам доверились полностью и не обратились к независимым тестировщикам. В результате процесс получается не совсем прозрачный и возникают проблемы. Обычно разработчики концентрируют усилия на обеспечении стабильной работы создаваемой или внедряемой системы, поэтому не так объективно оценивают качество кода. Даже когда разработчики находят баги, в их интересах скрыть находки. Так заказчик получает в пользование систему с ошибками, которые проявятся в любой момент.
Команда сторонних тестировщиков нужна, чтобы получить объективное представление об основных системных ошибках и принять необходимые меры по совершенствованию корпоративного ПО. Ключевая цель инженеров по тестированию — обеспечить наименьшее количество дефектов в продуктиве.
Виды и инструменты тестирования SAP-систем
На проектах SAP доступны стандартные виды тестирования: ручное (РФТ), автоматизированное (АФТ), нагрузочное (НТ). Узнать о них подробнее можно из статьи «Введение в тестирование: F.A.Q. новичка».
На сегодняшний день в «Аплане» семь активных проектов по тестированию SAP в трех направлениях (НТ, РТ И АФТ), пять из которых – проекты «СберТеха». Наши специалисты проводили тестирование SAP для X5 Retail Group, TELE2, METRO, «Мегафон», «Сибур», «Юлмарт» и других компаний. Всего на проектах SAP задействовано более восьмидесяти инженеров в трех городах: Москва, Санкт-Петербург и Нижний Новгород.
Один из наиболее популярных инструментов для автоматизированного нагрузочного тестирования SAP — HP LoadRunner. Эта утилита состоит из следующих приложений: Virtual User Generator (для разработки нагрузочных скриптов), Load Generator (для генерации виртуальных пользователей), Controller (для разработки и запуска сценариев нагрузки) и Analysis (для анализа результатов нагрузочного тестирования).
Наши инженеры по тестированию использовали HP LoadRunner для проверки надежности SAP-систем при работе над нагрузкой для крупнейшего нефтехимического холдинга России, ведущего мобильного оператора и банка с самой широкой сетью подразделений. Результаты нагрузочного тестирования позволяют оперативно определить максимальную производительность внедряемых или используемых SAP-систем, выявить и устранить проблемы при длительной работе под стандартной нагрузкой, а также при восстановлении систем после пиковой нагрузки.
Для интеграционного нагрузочного тестирования специалисты «Апланы» часто используют собственные инструменты SAP или Apache JMeter. Утилита JMeter разрабатывалась как средство тестирования web-приложений, но с помощью нее можно проводить нагрузочные тесты для JDBC-соединений, FTP, LDAP, SOAP, JMS, POP3, IMAP, HTTP и TCP.
Утилиту Apache JMeter в сочетании с JIRA Zephyr и Confluence наши тестировщики использовали на проекте по функциональному и интеграционному нагрузочному тестированию SAP в крупнейшем российском частном интернет-холдинге, специализирующимся на сегменте электронной коммерции.
Кроме того, для нагрузочного тестирования используются IBM Performance Tester, MS Visual Studio Ultimate и пр.
Ручное функциональное тестирование
Для ручного тестирования SAP-систем инженеры «Апланы» считают эффективными такие инструменты, как HP ALM, JIRA Zephyr, Confluence, SAP Solution Manager и другие. В основном для функционального тестирования SAP используются именно ручные тесты, но на крупных и долгосрочных проектах удобнее использовать автоматизированные. С помощью авто-тестов можно без потери качества протестировать тот же объем, но за меньшую стоимость и меньшее время.
Автоматизированное функциональное тестирование
Популярный инструмент для автоматизирования SAP — их собственный фреймворк — Component based Test Automation (CBTA), который интегрирован вместе с системой управления тестированием в Solution Manager (SM). Узнать подробнее о CBTA и других инструментах можно будет в следующем материале — «Автоматизированное тестирование SAP».
Благодарим за помощь в подготовке материала директора проектов компании «Аплана» —Константина Синанова, старшего инженера-тестировщика — Никиту Потапова и заместителя руководителя направления тестирования — Николая Стрельцова.