Архив метки: тестирование

Крутяк! Организация тестирования

Рассказываю вам крутяк. Организуем тестирование системы олдскульным способом – в самой ERP.

Транзакция STWB_1. Создаем каталог тестов. В нем есть три основные возможности. Создание ручных тестов (аля MS Excel, MS Word), автоматизированных в eCATT, внешних (через внешнюю программу).

Для примера я накидал два теста для себя.

Все на вражеском, ибо мне нужно для зарубежного блога на английском. Так что звиняйте.

Читать далее

Автоматизация тестирования SAPUI5 и Fiori приложений. Часть 1

Рано или поздно сложность разработки приложений, многообразие способов взаимодействия с пользователем, скорость изменения технологий приводят к необходимости все более тщательной проверки функционирования приложения. Внешне простое приложение на экране телефона часто содержит большое количество строк кода и логики, схем взаимодействия с внешней средой. Сегодня, во времена «облачной революции» в Сети, мы все чаще работаем с сервисами, которые предоставляют нам услуги. То же простое приложение может использовать не один сервис, а несколько и даже из разных мест. Например, заявка на отпуск может вызывать сервисы для получения персональной информации о сотруднике, о его руководителе, об остатке дней отпуска, о проверке возможности зарезервировать дни отпуска, – это все частные сервисы, выраженные функциями в системе SAP HCM, но функционирующими как сервисы.

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

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

Другая часть приложения обычно отвечает за взаимодействие с пользователем. В приложении есть табличная форма заявок на отпуск, несколько кнопочек, включая кнопочку «Создать». На одном телефоне, где программист тестировал приложение, все работает отлично. На телефоне соседа табличка заезжает за поля экрана, кнопочку не видно. На компьютере кнопочка «Создать» не реагирует на нажатие, а у Ивана при нажатии на кнопку «Обновить» приложение завершает свою работу.

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

SAPUI5 основан на «китах Интернета» в лице HTML структуры, CSS разметки, JavaScript кода. Приложения, которые мы видим на экранах, созданы с помощью этих элементов статически или динамически. Когда мы нажимаем на кнопочку «Создать», то открывается новое окно. Мы заполняем его информацией и отправляем на сервер для создания записи в базе данных. Это уже целый процесс, где задействованы элементы экрана, коды для формирования запроса серверу и анализа результата. Раз все формализовано, то мы можем проверить работу процесса автоматизировано с помощью специальных инструментов.

Рассмотрим работу кнопки «Создать». По нажатию на кнопку происходит обращение к серверу (в общем случае) с запросом формы для окна создания новой записи. Сервер обрабатывает запрос и присылает необходимые поля, их оформление для визуализации на экране. Для пользователя это просто смена картинки, для автоматизированного теста это многоступенчатый процесс, который нужно проверить в нескольких ракурсах:

  • После нажатия на кнопку сформировался ли запрос к серверу?
  • Сервер вернул положительный ответ или ошибку?
  • Положительный ответ сервера, это страница с формой для ввода данных или что-то другое?
  • Форма для ввода данных содержит поля, которые мы ожидали или другие?
  • Форма для ввода данных осуществляет проверку на формат вводимых данных?

Выше приведен пример простейших тестов, которые должна выполнить система автоматизированного тестирования для проверки одной пользовательской операции «Создать». Если перемножить количество операций на вариативность сред для выполнения приложения и на возможные ракурсы, то мы понимаем, что без автоматизации не обойтись.

Предлагаю об этом нам и поговорить в следующих заметках.

Короткий тест на знание SAP HCM от Поцелуева

Привет.

Меня попросили, а не отказался. Короткий тест от меня на знание HR. Если понравится идея, то выложу еще 40 вопросов 🙂 Заказчик иностранец, так что сорри за кривой английский.

SAP HCM Test 10 questions

Всем привет. Пробный тест по HCM 🙂

Виды тестирования

Привет.

Предлагаю договориться о понятиях.

Компонентное тестирование. Тестирование конкретной функции, настройки. Например, расчет вида оплаты, ввод инфотипа, формирование отчета. Это шаг процесса.

Функциональное тестирование. Тестирование процесса из нескольких шагов. Формирование табеля рабочего времени (ввод данных, оценка времени, форма Т-13).

Интеграционное тестирование. Тестирование смежных процессов, процессов, переходящих из одного функционала в другой. Например, увольнение с расчетом, расчет зарплаты с формированием проводок.

Приемо-сдаточное тестирование (UAT). Тестирование пользователями, которые принимают систему. Комплексное тестирование, которое охватывает элементы компонентного, функционального и интеграционного тестирования в зависимости от выполняемых пользователем функций.

Регрессионное тестирование. Тестирование уже работающего функционала после внесения изменений в систему. Нужно для того, чтобы проверить, что ничего не сломалось после изменений. Например, изменение правила расчета среднего для вида оплаты ХХ не повлияло на расчет прочих средних.

Нагрузочное тестирование. Тестирование работоспособности системы под нагрузкой большого количества пользователей или операций. Например, портал работает при плохом соединении и при одномоментном входе 100, 500, 1000 и 10 000 пользователей.

Что я упустил?

Тестируем

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

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

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

ecatt_1

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

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

ecatt_2

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