Да, виноват. Вы честно проголосовали за демонстрацию, набрали более 100 голосов. Поэтому «спустя годы» я расскажу вам сказку, как начать тестировать функционал в системе SAP. О методиках, принципах и подходах мы говорили ранее, сегодня только практика. Начинать будем, как всегда, с простых примеров, чтобы понять логику, а затем ее развить. Представляю вашему вниманию пошаговое руководство для тестирования SAP решений с помощью бесплатного инструмента SAP eCATT.
Настраиваем систему для организации тестирования eCATT
Для начала работы нам нужен мандант, в котором будут активированы две вещи.
- Разрешено выполнение eCATT (транзакция SCC4).
Эта штука полезна тем, что мы можем выделить отдельный мандант в системе (или другой системе), где система будет заходить и тестировать функционал. Например, в одной системе мы разрабатываем тесты, а в копию продуктива SAP сам заходит, запускает тесты удаленно и показывает результат. При этом не обязательно предоставлять доступ консультантам к такой копии, ибо низзя.
- Разрешен GUI Scripting для записи и воспроизведения последовательности шагов пользователя. Транзакция RZ11, параметр sapgui/user_scripting нужно установить в TRUE.
И тут мы открываем транзакцию SECATT.
Базовые объекты eCATT
Для начала давайте разберем основные штуки, которые есть на экране.
-
- Конфигурация теста
Конфигурация теста это общая штука, которая говорит как запускать тест, с какими данными, в какой системе. Поэтому и называется конфигурацией, что позволяет определять параметры работы теста.
-
- Тест-скрипт
Собственно говоря и есть сам тест с набором шагов-действий-проверок, которые выполняются системой для проверки работы функции, программы, процесса.
-
- Объект проверки
Какая-то офигенная штука, но непонятная. Не пробовал. Говорят, что позволяет заранее создать объекты для бизнес-проверок. Например, «Сохранение инфотипа». И присвоить три категории бизнес-результата теста: прошел, провалил, свалил техническая ошибка. Один раз присваиваем системные сообщения, которые могут возникать при сохранении инфотипов и в дальнейшем вставляем в тесты. Выглядит удобно.
-
- Данные теста
Сами данные, которые мы хотим скормить тесту на входе, чтобы он их подставил в нужные места. Данные можно указать константами, загружать из внешних файлов. Не нашел как формировать динамически, что плохо. Но можно выкрутиться создавая данные теста в абапе или внешнем файле, а потом скармливать тесту. Он же голодный, тест-то.
-
- Системные данные
Это элементарно. Данные системы, где поджигать фитиль. Либо в локальной системе, где сам тест создается, либо RFC до черта на куличках. Или несколько систем, если у нас разные ландшафты (например, при регрессионном тестировании при обновлении).
-
- Профиль запуска
Это вообще раз плюнуть. Как запускать тест в системе. С отладкой или без, с протоколированием или без, онлайн или в фоне, покрытие тестом ABAP кода.
Запись скрипта в eCATT
Почитали мы этот фарш кнопочек, пора бы и начать. Ставим задачу. Базовый уровень тестов — проверка допустимости ввода и сохранения данных в систему. Второй уровень — алгоритмы. Третий — интеграционный. Все как в классической модели организации тестирования на проектах. Если говорить на человеческом языке, то нам нужно выбрать табельный номер, выбрать инфотип, указать даты, создать запись с видом оплаты, сохранить. При этом нужно проверить результат — сохранение успешно. Также нужно сделать негативный тест — проверить, что система корректно отрабатывает ошибочную ситуацию — данные не сохраняются при неверном заполнении полей инфотипа.
Создаем тест-скрипт.
Нижнее поле, это редактор шагов теста. Кликаем на него и нажимаем правую клавишу мыши — вставить образец. Количество команд разнообразно. Нам сейчас нужно имитировать ввод данных, поэтому мы выбираем следующую комбинацию.
Эта комбинация означает запись всех шагов пользователя с помощью технологии GUI Scripting, о которой я писал ранее.
Заполняем транзакцию и записываем сценарий. Показывать не буду, все стандартно.
Единственное на что следует обратить внимание, это на окошко, которое открывается параллельно с новым режимом. Окно управления записью.
Из интересных кнопочек можно отметить две.
GETGUI — получить информацию с экрана в переменную теста.
CHEGUI — вставить контрольную проверку на состояние элемента экрана. Иными словами проверить, есть ли такое-то значение/состояние у элемента.
Остановить запись очевидна.
После завершения записи у нас получается такая картинка. Если два раза жмакнуть на параметр функции SAPGUI , то откроется окно с деталями (справа внизу).
Мы записали первую команду теста. У меня на это ушло 1 минута, включая создание теста.
Теперь давайте изучим сам сценарий. В среднем окне вы видите названия экранов, также, как и при записи LSMW. Форма отображения несколько иная, но суть остается той же. Если развернуть шаги, то мы увидим введенными нами значения и иную информацию, включая технические параметры сообщения, что запись успешно сохранена.
Нам, как и в LSMW, нужно создать эти параметры для теста, чтобы потом можно было в эти параметры передавать значения из файлов или данных теста (см выше главный экран SECATT). Для этого нажимаем кнопочку и подтверждаем нахальные намерения системы.
Осталось проверить результат теста — появление сообщения об успешности сохранения записи. Это сообщение с кодом PG102, которое вы можете увидеть в самом низу сценария теста.
В окне создания команд (самое левое) опять нажимаем правую клавишу мыши, выбираем вставку образца, группу контролей и вот так.
Правим текст в окне команд, чтобы MESSAGE/ENDMESSAGE охватывали внутри себя наш скрипт:
MESSAGE ( MSG_1 ).
SAPGUI ( SAPGUI_1 ).
ENDMESSAGE ( E_MSG_1 ).
Создаем справа параметры сообщения для проверки.
Тест готов.
Выполнение сценария тестирования в eCATT
Можно запускать.
Я думаю, что в первый раз у вас тест не заработает. Наверное вы забыли удалить уже созданную запись инфотипа, а настройки не позволяют в один день создавать две записи 😉
Оставайтесь на связи. Жду комментариев 🙂 Ваш я.