Антон Гупаленко, QA engineer в DonDiver Я расскажу о нашем опыте тестирования backend части финансовой платформы. О том какие инструменты мы применяли, на какие “грабли” натыкались и как тестируем API сейчас.

1. QA Meetup
Best practices тестирования API
Гупаленко Антон

2. DreamPayments.com
Мы тестируем back end:
● управление пользователями
● проведение платежей
● взаимодействие с банками
● финансовые операции
● активация и управление терминалом
● каталог продуктов
● отчеты и статистика

3. Стек технологий
взаимодействие с front end через SOAP и REST

4. Принципы при проверки API:
● API поддерживает требуемые сценарии
● запрос API удовлетворяет спецификации
● валидация ответа на полноту данных
● валидация корректности данных в ответе

5. Принципы при проверки API:
● валидация изменений в DB
● проверка работы внешних сервисов
● это не unit тесты

7. ● используем groovy для автоматизации заполнения
запросов и проверки ответов
● используем groovy и db2 jdbc для написания проверок
в базе
● механизм переиспользования кейсов
● взаимодействие с внешними системами (e-mail, sftp)

8. Плюсы:
● простота разработки тест кейсов
● наглядность при работе в запросами и ответами
● возможность быстро использовать созданные кейсы
● возможность использовать groovy и сторонние
библиотеки
● возможность проверки без написания теста

9. Минусы:
● скорость работы и потребление ресурсов
● сложность подготовки проверок
● переиспользование возможно, но требует больших
усилий
● отсутствие удобного IDE

10. Проблемы, с которыми мы столкнулись:
● переиспользование flow целиком
● механизмы для проверок находились в разных местах,
их трудно структурировать
● при запуске тестов трудно понять, что конкретно
поломано API или сам тест

11. Проблемы, с которыми мы столкнулись:
● поддержка тестов командой становиться все труднее
● не возможно работать над одним кейсом совместно
● трудно собирать статистику по прогону теста
Количество тестов: 5000, время полного прогона 18 часов

12. Решения проблем:
● создали DataGenerator и постарались максимально
отойти от переиспользования flow
● все имеющие проверки базы данных перенесли в
groovy библиотеку
● создали новый фреймворк с использованием JAVA +
jUnit

13. Java фреймворк

14. Что есть в фреймворке:
● Java и jUnit
● объекты реквестов и реплаев из кода
● валидатор проверяет весь ответ
● DataGenerator, пул различных данных
● шаблоны тестов для типичных проверок
● e-mail валидатор
● Allure, как средство построения отчетов

15. Плюсы:
● гибкость при разработке тестов
● понятная структура тестов и вспомогательных
методов
● возможность параллельного запуска тестов
● возможность категоризировать тесты
● помощь DEV команды, как при разработке
фреймворка, так и при написании тестов
Количество тестов: 4000, время полного прогона 4 часа

16. Минусы:
● выше порог вхождения
● наглядность тестов падает
● нет возможности вручную проверить API
● контроль за кодом тестов

17. Best practice:
● проверять все поля полученные в ответе
● не переиспользовать flow
● генерировать данные
● разбивать тесты по категориям и
критичности
● проверять внешние сервисы
● следить за состоянием тестов

18. Контакты:
email: anton.gupalenko@donriver.
com
skype: anton_gup
Email: resume_rus@donriver.com