API в автотестах
Функциональный тестировщик на одном из банковских проектов DexSys рассказала о том, как на ее проекте внедряли API в процессы тестирования.
Старт интеграционных проверок мобильного приложения
Процесс тестирования на одном из наших банковских проектов построен в виде двухнедельных трейнов, состоящих из двух циклов. Каждый цикл трейна проверяется на отдельных стендах, поэтому все кейсы мы рассматриваем по 2 раза. Наша команда «Управление обеспечения качества» проводит интеграцию функционала, реализованного в приложении банка.
Увеличение функционала
Если для проверки кейсов в web-интерфейсе нужен только рабочий ПК, то для проверки iOS и Android нужны реальные устройства. Территориально наша команда разбросана по разным городам: Москва, Санкт-Петербург, Обнинск, Краснодар, Ижевск, Рязань и т.д. Приобретать в каждую из локаций устройства накладно. Ко всему прочему, проблему усложнил перевод большей части сотрудников на удаленный формат работы из-за «пандемии» в 2020 году. Часть банковских офисов в этот период работала в ограниченном режиме. При этом увеличивался функционал, доступный в мобильном приложении, соответственно, увеличивалось и количество кейсов в рамках трейна. Проверка интеграционных кейсов занимала все больше ресурсов и становилась все более трудоемкой. Чтобы решить эту проблему мы приняли решение переводить кейсы на API.
Что такое API?
API- это Application Programming Interface или программный интерфейс приложения, с помощью которого одна программа может взаимодействовать с другой.
С помощью API можно получать информацию из одной системы и отправлять ее в другую, интерфейс пользователя при этом не используется. Количество вызовов сервисов зависит от бизнес-процесса и количества связанных с бизнес-процессом систем
Тестирование API – это тип тестирования ПО, который включает тестирование интерфейсов прикладного программирования напрямую и в рамках интеграционного тестирования.
При API-тестировании можно выявить интеграционные ошибки взаимодействия между системами, модулями системы, не проверяя при этом UI.
Разработка приложения использует API, поэтому и приоритет в разработке автоматизированных кейсов остался за API. Данный тип тестирования выполняется значительно быстрее, так как не нужно ожидание получения фронта приложения.
В первом приоритете в реализацию были включены кейсы, выполняемые на мобильных устройствах. Для сбора последовательности выполнения вызовов использовали сбор логов в Fiddler, это инструмент отладки прокси-сервера, для выполнения проверок в эмуляторе — Android. По вопросам передачи и получения параметров обращались к документации или к разработчикам приложения/микросервисов, по бизнес-процессам к аналитикам.
Первые успехи и новые трудности
Первоначальный проект автоматизированных кейсов работы мобильного приложения был реализован в Soap UI. При первом же использовании API в трейне сильно сократилось время, затрачиваемое на проверки. Если на проверку одного кейса на мобильном устройстве раньше тратили час, то в Soap UI кейс отрабатывали за 3-5 минут. Через 7-8 трейнов количество API-кейсов увеличилось, и проект для Soup UI тоже увеличился.
Но тут мы столкнулись с другой проблемой: состав команды тестирования меняется регулярно, и для каждого нового сотрудника проект API в Soap UI требовал определенное количество времени на настройку, установку нужного ПО, ввод данных для авторизации и т.п.
Учитывая время, требуемое для обновления проекта после добавления новых API-сценариев, доработки существующих и т.п. – мы пришли к тому, что проект API стал сложным для установки и доработок.
Реализация в АТ и использование Report Portal
Проверки UI Web-интерфейса, и других систем были реализованы на платформе АТ и ставились на автоматический запуск. Тут настройка для каждого сотрудника не требовалась. Добавление новых сценариев в проект API для SOAP UI приостановили, но наша автоматизация на этом не остановилась.
Решено было переводить API на платформу автотестирования, которая использовалась для остальных систем или проектов.
Основная сложность заключалась в том, что все проекты использовали для написания автотестов язык Gherkin. Но в нем не было шагов, подходящих для нашего API. Так что нашим коллегам из команды Автотестирования нужно было с нуля написать эти команды.
В результате были реализованы такие шаги: поиск клиента, получение клиентских данных для авторизации и т.п., которые выполняли запросы последовательно, по аналогии с SOAP UI.
По результатам анализа реализованных сценариев мы выделили основные шаги: последовательность выполнения авторизации, ввод СМС-кода, выполнение переводов/оплаты, подключение услуг и т.д., и наименования этих шагов сформулировали на понятном функциональному тестировщику синтаксисе. Это сделало наш проект более понятным начинающим тестировщикам.
Начинали с простых кейсов по авторизации
Последовательно все сценарии из проекта Soup UI мы перевели на платформу автотестирования, на которой можно настраивать расписание запуска автотестов, стенд, количество перезапусков. В то время пока проект API переписывали на Gherkin, в список ручных проверок добавился новый функционал: увеличилось количество оформляемых продуктов. Теперь часть проверок мы автоматизировали быстрее. Если до автоматизации кейсы по выполнению переводов мы выполняли только для одного вида продуктов, то после реализации расширили покрытие и теперь проверяем сразу для нескольких, не увеличивая трудозатраты.
На следующем этапе мы реализовали подготовку тестовых данных для API в рамках АТ UI других систем. Также доработали в API поиск и подхват подготовленных данных из другого проекта, что также сократило время ручной работы с АТ.
Для части проверок нам было сложно найти подходящие тестовые данные, создание которых вручную было бы нецелесообразно. Запрашивали реализацию новых и доработку существующих сервисов по поиску клиентов.
Что получили?
На сегодняшний день автотестами API+UI покрываются 61% проверок. Мы ведем активную работу по постановке задач на реализацию новых API-сценариев. Большую часть сценариев нового функционала мы реализовываем в API через 2-3 трейна. Доработка существующего функционала оперативно анализируется и задачи на доработку создаются в рамках идущего трейна.
Визуально мы не видим API-вызова — у нас реализован удобный, доработанный функционал, для работы с которым не требуется знаний и опыта работы с Soup UI, Postman и другими инструментами работы с API. Благодаря этому расширяются возможности по работе с ресурсом и ускоряется процесс погружения в проект.
Процесс тестирования на одном из наших банковских проектов построен в виде двухнедельных трейнов, состоящих из двух циклов. Каждый цикл трейна проверяется на отдельных стендах, поэтому все кейсы мы рассматриваем по 2 раза. Наша команда «Управление обеспечения качества» проводит интеграцию функционала, реализованного в приложении банка.
Увеличение функционала
Если для проверки кейсов в web-интерфейсе нужен только рабочий ПК, то для проверки iOS и Android нужны реальные устройства. Территориально наша команда разбросана по разным городам: Москва, Санкт-Петербург, Обнинск, Краснодар, Ижевск, Рязань и т.д. Приобретать в каждую из локаций устройства накладно. Ко всему прочему, проблему усложнил перевод большей части сотрудников на удаленный формат работы из-за «пандемии» в 2020 году. Часть банковских офисов в этот период работала в ограниченном режиме. При этом увеличивался функционал, доступный в мобильном приложении, соответственно, увеличивалось и количество кейсов в рамках трейна. Проверка интеграционных кейсов занимала все больше ресурсов и становилась все более трудоемкой. Чтобы решить эту проблему мы приняли решение переводить кейсы на API.
Что такое API?
API- это Application Programming Interface или программный интерфейс приложения, с помощью которого одна программа может взаимодействовать с другой.
С помощью API можно получать информацию из одной системы и отправлять ее в другую, интерфейс пользователя при этом не используется. Количество вызовов сервисов зависит от бизнес-процесса и количества связанных с бизнес-процессом систем
Тестирование API – это тип тестирования ПО, который включает тестирование интерфейсов прикладного программирования напрямую и в рамках интеграционного тестирования.
При API-тестировании можно выявить интеграционные ошибки взаимодействия между системами, модулями системы, не проверяя при этом UI.
Разработка приложения использует API, поэтому и приоритет в разработке автоматизированных кейсов остался за API. Данный тип тестирования выполняется значительно быстрее, так как не нужно ожидание получения фронта приложения.
В первом приоритете в реализацию были включены кейсы, выполняемые на мобильных устройствах. Для сбора последовательности выполнения вызовов использовали сбор логов в Fiddler, это инструмент отладки прокси-сервера, для выполнения проверок в эмуляторе — Android. По вопросам передачи и получения параметров обращались к документации или к разработчикам приложения/микросервисов, по бизнес-процессам к аналитикам.
Первые успехи и новые трудности
Первоначальный проект автоматизированных кейсов работы мобильного приложения был реализован в Soap UI. При первом же использовании API в трейне сильно сократилось время, затрачиваемое на проверки. Если на проверку одного кейса на мобильном устройстве раньше тратили час, то в Soap UI кейс отрабатывали за 3-5 минут. Через 7-8 трейнов количество API-кейсов увеличилось, и проект для Soup UI тоже увеличился.
Но тут мы столкнулись с другой проблемой: состав команды тестирования меняется регулярно, и для каждого нового сотрудника проект API в Soap UI требовал определенное количество времени на настройку, установку нужного ПО, ввод данных для авторизации и т.п.
Учитывая время, требуемое для обновления проекта после добавления новых API-сценариев, доработки существующих и т.п. – мы пришли к тому, что проект API стал сложным для установки и доработок.
Реализация в АТ и использование Report Portal
Проверки UI Web-интерфейса, и других систем были реализованы на платформе АТ и ставились на автоматический запуск. Тут настройка для каждого сотрудника не требовалась. Добавление новых сценариев в проект API для SOAP UI приостановили, но наша автоматизация на этом не остановилась.
Решено было переводить API на платформу автотестирования, которая использовалась для остальных систем или проектов.
Основная сложность заключалась в том, что все проекты использовали для написания автотестов язык Gherkin. Но в нем не было шагов, подходящих для нашего API. Так что нашим коллегам из команды Автотестирования нужно было с нуля написать эти команды.
В результате были реализованы такие шаги: поиск клиента, получение клиентских данных для авторизации и т.п., которые выполняли запросы последовательно, по аналогии с SOAP UI.
По результатам анализа реализованных сценариев мы выделили основные шаги: последовательность выполнения авторизации, ввод СМС-кода, выполнение переводов/оплаты, подключение услуг и т.д., и наименования этих шагов сформулировали на понятном функциональному тестировщику синтаксисе. Это сделало наш проект более понятным начинающим тестировщикам.
Начинали с простых кейсов по авторизации
Последовательно все сценарии из проекта Soup UI мы перевели на платформу автотестирования, на которой можно настраивать расписание запуска автотестов, стенд, количество перезапусков. В то время пока проект API переписывали на Gherkin, в список ручных проверок добавился новый функционал: увеличилось количество оформляемых продуктов. Теперь часть проверок мы автоматизировали быстрее. Если до автоматизации кейсы по выполнению переводов мы выполняли только для одного вида продуктов, то после реализации расширили покрытие и теперь проверяем сразу для нескольких, не увеличивая трудозатраты.
На следующем этапе мы реализовали подготовку тестовых данных для API в рамках АТ UI других систем. Также доработали в API поиск и подхват подготовленных данных из другого проекта, что также сократило время ручной работы с АТ.
Для части проверок нам было сложно найти подходящие тестовые данные, создание которых вручную было бы нецелесообразно. Запрашивали реализацию новых и доработку существующих сервисов по поиску клиентов.
Что получили?
На сегодняшний день автотестами API+UI покрываются 61% проверок. Мы ведем активную работу по постановке задач на реализацию новых API-сценариев. Большую часть сценариев нового функционала мы реализовываем в API через 2-3 трейна. Доработка существующего функционала оперативно анализируется и задачи на доработку создаются в рамках идущего трейна.
Визуально мы не видим API-вызова — у нас реализован удобный, доработанный функционал, для работы с которым не требуется знаний и опыта работы с Soup UI, Postman и другими инструментами работы с API. Благодаря этому расширяются возможности по работе с ресурсом и ускоряется процесс погружения в проект.