Тестируем

Да, виноват. Вы честно проголосовали за демонстрацию, набрали более 100 голосов. Поэтому «спустя годы» я расскажу вам сказку, как начать тестировать функционал в системе SAP. О методиках, принципах и подходах мы говорили ранее, сегодня только практика. Начинать будем, как всегда, с простых примеров, чтобы понять логику, а затем ее развить.

Для начала работы нам нужен мандант, в котором будут активированы две вещи.

  • Разрешено выполнение eCATT (транзакция SCC4).

ecatt_1

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

  • Разрешен GUI Scripting для записи и воспроизведения последовательности шагов пользователя. Транзакция RZ11, параметр sapgui/user_scripting нужно установить в TRUE.

ecatt_2

И тут мы открываем транзакцию SECATT.

Для начала давайте разберем основные штуки, которые есть на экране.
ecatt_3

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

  • Тест-скрипт
  • Собственно говоря и есть сам тест с набором шагов-действий-проверок, которые выполняются системой для проверки работы функции, программы, процесса.

  • Объект проверки
  • Какая-то офигенная штука, но непонятная. Не пробовал. Говорят, что позволяет заранее создать объекты для бизнес-проверок. Например, «Сохранение инфотипа». И присвоить три категории бизнес-результата теста: прошел, провалил, свалил техническая ошибка. Один раз присваиваем системные сообщения, которые могут возникать при сохранении инфотипов и в дальнейшем вставляем в тесты. Выглядит удобно.

  • Данные теста
  • Сами данные, которые мы хотим скормить тесту на входе, чтобы он их подставил в нужные места. Данные можно указать константами, загружать из внешних файлов. Не нашел как формировать динамически, что плохо. Но можно выкрутиться создавая данные теста в абапе или внешнем файле, а потом скармливать тесту. Он же голодный, тест-то.

  • Системные данные
  • Это элементарно. Данные системы, где поджигать фитиль. Либо в локальной системе, где сам тест создается, либо RFC до черта на куличках. Или несколько систем, если у нас разные ландшафты (например, при регрессионном тестировании при обновлении).

  • Профиль запуска
  • Это вообще раз плюнуть. Как запускать тест в системе. С отладкой или без, с протоколированием или без, онлайн или в фоне, покрытие тестом ABAP кода.

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

Создаем тест-скрипт.
ecatt_4

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

ecatt_5

Эта комбинация означает запись всех шагов пользователя с помощью технологии GUI Scripting, о которой я писал ранее.
Заполняем транзакцию и записываем сценарий. Показывать не буду, все стандартно.

ecatt_6

Единственное на что следует обратить внимание, это на окошко, которое открывается параллельно с новым режимом. Окно управления записью.

ecatt_7

Из интересных кнопочек можно отметить две.
GETGUI — получить информацию с экрана в переменную теста.
CHEGUI — вставить контрольную проверку на состояние элемента экрана. Иными словами проверить, есть ли такое-то значение/состояние у элемента.
Остановить запись очевидна.

После завершения записи у нас получается такая картинка. Если два раза жмакнуть на параметр функции SAPGUI , то откроется окно с деталями (справа внизу).

ecatt_8

Мы записали первую команду теста. У меня на это ушло 1 минута, включая создание теста.
Теперь давайте изучим сам сценарий. В среднем окне вы видите названия экранов, также, как и при записи LSMW. Форма отображения несколько иная, но суть остается той же. Если развернуть шаги, то мы увидим введенными нами значения и иную информацию, включая технические параметры сообщения, что запись успешно сохранена.

Нам, как и в LSMW, нужно создать эти параметры для теста, чтобы потом можно было в эти параметры передавать значения из файлов или данных теста (см выше главный экран SECATT). Для этого нажимаем кнопочку и подтверждаем нахальные намерения системы.

ecatt_9

Осталось проверить результат теста — появление сообщения об успешности сохранения записи. Это сообщение с кодом PG102, которое вы можете увидеть в самом низу сценария теста.

ecatt_10

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

ecatt_11

Правим текст в окне команд, чтобы MESSAGE/ENDMESSAGE охватывали внутри себя наш скрипт:
MESSAGE ( MSG_1 ).
SAPGUI ( SAPGUI_1 ).
ENDMESSAGE ( E_MSG_1 ).

Создаем справа параметры сообщения для проверки.

ecatt_12

Тест готов.

Можно запускать.
ecatt_13

Я думаю, что в первый раз у вас тест не заработает. Наверное вы забыли удалить уже созданную запись инфотипа, а настройки не позволяют в один день создавать две записи 😉

Оставайтесь на связи. Жду комментариев 🙂 Ваш я.

Тестируем: 1 комментарий

  1. Calm

    Очень интересно, спасибо!
    Попробую обязательно.

Добавить комментарий