2. About me
• Ex-Developer
• В IT более 10 лет
• 4 из них в тестировании
• Senior QA @ T-Systems CIS
linkedin.com/in/qapavlov
ru.apavlov@gmail.com
3. Что такое API?
API (application programming interface) — набор готовых классов, процедур,
функций, структур и констант, предоставляемых приложением
(библиотекой, сервисом) для использования во внешних программных
продуктах.
4. А если нормально?..
Если программу рассматривать как чёрный ящик, то API — это множество
«ручек», которые доступны пользователю данного ящика и которые он
может вертеть и дёргать.
Высокоуровневые компоненты используют API низкоуровневых
компонентов, а те, в свою очередь, используют API ещё более
низкоуровневых компонентов.
7. Зачем API вообще нужны?
Давным-давно - Data Scraping.
Результатом было:
• Неверное истолкование данных
• Неудобный формат данных
• Компании теряли клиентов, если приложение предоставляло
неправильную информацию
Тогда компании задумались о реализации получения доступа к данным на
своей стороне.
8. Зачем API вообще нужны?
API предоставляет компаниям:
• Больше контроля над данными
• Контроль над использованием данных:
o Для использования API необходима авторизация
o Разработчик приложения должен доказать, что это приложение
корректно работает на тестовых данных прежде, чем получит
доступ к API
Так же API дают возможности:
• Масштабирования разработки
o Возможность увеличивать объем данных приложения, без
изменения самого приложения
• Преобразования конкурентов в партнеров
o Возможность позволить конкурентам надстраивать что-то сверху
вашего продукта
• Дополнительные полномочия для пользователей
o Возможность людям использовать продукт для вещей,
для которых он не был разработан
• Открытие нового рынка
9. Использование API
API включает в себя:
• Разделение данных и их представление
• Точка входа (изначальный URL, http или https),
• Навигация
• Представление вида командной строки
• Иерархия
• Ресурсы
• Структура
• Конфиденциальные данные (private API)
12. Что нужно учитывать при создании
стратегии
• Архитектура
o REST vs. SOAP
o Stateless vs. Session
o Media types vs. WSDL
• text/xml или application/vendor specific
o Verbs (RESTful API) и другие специфичные вещи
o Headers и кеширование запросов
• Tools
o SoapUI, Fiddler, аддоны для браузера (Postman, etc.)
13. Внимательно!
Особенно стоит уделить внимание особенностям протокола, например,
Verbs в RESTful API, заголовкам и кешированию.
К примеру, в случае с кэшами, нужно быть готовым к таким вещам, как:
– Старые данные
– Не относящиеся к происходящему ошибки (закешированные ранее)
– Многослойное кэширование (приложение – API – сервер)
14. Основные риски при создании стратегии
• Неясный процесс интеграции
• Огромное количество данных
• Невозможность тестирования end-to-end сценариев
• Неизвестная нагрузка
• Возможное неправильное понимание API
• Динамический скоуп
15. Стратегия тестирования мобильных API
Что же должно быть в самой стратегии?
• Как можно раньше должен быть проведен тест на интеграцию с
максимально полной инфраструктурой
• Тест на интеграцию c использованием кастомных фреймворков во
время разработки и систеста
• Многократные фазы интеграции
• Тестирования прототипа на реальных устройствах (acceptance testing)
17. Какие фазы мы должны выделить в нашей
стратегии?
1. Development (включая фреймворк для тестирования)
2. System testing (используя моки)
3. Integration testing (API с бэкэндом)
4. Acceptance testing (API на прототипе)
5. Production integration (пофазно)
6. Regression testing (автоматизация)