Если бы я спросил вас “Каковы основные признаки сильного API?”, что бы вы ответили? Обозначили бы вы надежность? Документированность? Безопасность? Удобство для разработчика?
Вы можете удивиться, узнав, что большинство людей не упоминают производительность. Как быстро выполняется этот API? Объективно они об этом могут и не задумываться, но подсознательно точно ощущают.
Если вы используете новый API впервые и на его ответ уходит пять секунд, то вряд ли вас это порадует. На дворе 2021 — ответ не должен занимать больше секунды.
Задумываемся мы об этом или нет, но производительность мы оцениваем так же (если не более) требовательно, как и любую другую метрику. Именно она определяет удобство и пользовательский опыт. Мы не хотим, чтобы пользователи ожидали выполнения того или иного действия. Оно должно происходить автоматически и без задержек.
Так что же делать?
Установка приемлемых параметров
Для начала нам потребуется ответить на вопрос: “Что значит производительный?”. Каких показателей должен достичь ваш API, чтобы вы сочли его скорость приемлемой? При тестировании производительности чаще всего отслеживают две метрики:
- Среднее время выполнения — средняя скорость отклика API по всем вызовам.
- P99/максимальное время выполнения — наименьшая скорость отклика.
P99 означает 99%. Т.е. 99% запросов должны вписываться в определенный порог времени. При этом нет ничего страшного, если 1% будет этот порог перешагивать. Аномалии случаются — это просто закон жизни. Поэтому измерение по критерию 99% будет давать устойчивые результаты и исключать возможные отклонения.
При определении параметров не забывайте, что они должны быть приемлемыми, а не идеальными. В совершенном мире отклик API составлял бы миллисекунды, но в реальности вполне сгодится средняя скорость в районе 500мс.
Конечные пользователи, как правило, начинают обращать внимание на задержки, спустя секунду ожидания. Если же им приходится ждать дольше пяти секунд, то чаще всего они просто уходят с сайта. Поэтому стремитесь поддерживать p99 в диапазоне 1 000–1 200мс.
Настройка тестов производительности
Подобрав приемлемые параметры, можно переходить к фактическому тестированию производительности.
Все, что делает такой тест — это обращается к вашему API и записывает время отклика, поэтому автоматизировать этот процесс будет достаточно легко.
С помощью инструментов, наподобие Postman, вы можете определить структуру API непосредственно в приложении и выполнять автоматические тесты как самостоятельно при желании, так и по расписанию.
Я создал на GitHub коллекцию Postman и среду, которая будет принимать определение вашего API, преобразовывать его в серию тестов производительности, обращаться к API настраиваемое количество раз и возвращать среднее и максимальное время выполнения для каждой конечной точки.
Так что можете расслабиться — делать вам ничего не придется! Потребуется, конечно, импортировать исходный код с GitHub и настроить несколько переменных среды, но на этом все!
Переменные среды
Перед запуском коллекции тестов нужно установить переменные среды:
env-apiKey— ключ интеграции API для Postman (строка) — документация Postman по ключам API.env-server— название среды, которую вы хотите запустить. Это значение соответствует свойствуdescriptionв объектеServersопределения API (строка).env-performanceIterations— сколько раз должна быть выполнена каждая конечная точка API из документа определения (целое число).env-performanceAverageMs—порог (мс), определяющий каким должно быть среднее время отклика каждой конечной точки (целое число).env-performanceP99Ms— порог (мс), определяющий максимальное допустимое время отклика для конечной точки (целое число).- Определить нужно либо
env-apiIds, либоenv-workspaceId. - Если установить
env-apiIds, генератор будет тестировать все Postman API с переданными id (массив строк). - Если определить
env-workspaceId, генератор будет тестировать все API в указанном рабочем пространстве Postman (string).
Определение API
Важнейшая часть генератора — это файл определения вашего API. Нужно, чтобы этот документ был написан по стандарту Open API Specification v3 в JSON или YAML.
Я несколько раз писал об этой спецификации и настоятельно рекомендую ознакомиться с ее структурой, так как она постепенно становится индустриальным стандартом для определения API.
Чтобы генератор корректно работал с определением API, во всех конечных точках этого API должна присутствовать схема тела запроса (если это возможно), содержащая образец значения для каждого свойства. Именно их генератор использует для передачи в API.
Прописывание для всего примеров значений может показаться утомительным, но с другой стороны вы получаете бесплатные динамические тесты производительности (а также контрактные тесты и тесты безопасности) плюс хорошую описательную документацию API, которую для вас генерирует Postman. Сплошные выгоды!
Полный рабочий пример определения API можете взять с моего Gopher Holes Unlimited API.
Запуск тестов
Настроив переменные среды и правильно определив спецификацию Open API, вы можете перейти к главному. Сначала мы выполним все вручную.
- Кликните в Postman по кнопке Runner.
- Выберите коллекцию Performance Test Generator.
- Выберите в пункте Environment “Performance Generator Environment”.
- Нажмите Run Performance для начала выполнения.
Генератор начнет создавать тесты и обращаться к вашему API.
Если вы захотите выполнять эту задачу автоматически, то можете настроить мониторинг, чтобы тесты запускались по расписанию. Для этого выполните следующее:
- Нажмите правой кнопкой мыши по коллекции Performance Test Generator в рабочем пространстве и выберите Monitor Collection.
- В пункте “Use an environment (optional)” выберите Performance Generator Environment.
- Выберите частоту выполнения коллекции.
- Нажмите Create.
Теперь ваши тесты будут выполняться по расписанию. Самое же интересное в том, что, поскольку этот процесс подразумевает динамическую загрузку определения API и создание тестов на его основе, вам не придется заниматься его обслуживанием. Обновление будет происходить всякий раз при создании вами определения.
Результаты тестов
После выполнения генератор проанализирует результаты:
- Было ли среднее время ответа меньше установленного в среде?
- Было ли максимальное время отклика ниже установленного p99 в среде?
- Были ли как минимум половина ответов успешными (код состояния 2XX)?
Как видите, моему Gopher Holes Unlimited API требуется доработка. Одна конечная точка дает сбой в 100% случаев, и еще одна отзывается слишком медленно.
Эти результаты можно использовать по своему усмотрению. Сбои здесь обуславливаются реализацией API. Если же скорость ниже определенного порога, то нужно искать возможность этот API ускорить.
Если же сбой дают более половины ответов, то либо у вас ошибка в API, либо образцы значений в документе определения прописаны ошибочно. В любом случае исправление этих проблем сделает ваш API надежнее.
Заключение
Помните, что быстрый API производит уверенное впечатление надежности, которое оставит ваших клиентов довольными и поможет бизнесу развиваться.
Рассмотренные тесты являются низкозатратным и очень ценным компонентом процесса разработки API. Поскольку вам больше не потребуется тратить время на создание и обслуживание тяжелых тестов производительности, то можете уделить это время более ценным вещам — например, решению бизнес-задач или расширению функционала.
Чем бы вы ни занимались, надеюсь генератор окажется вам полезен. Он разрабатывался с целью экономии времени и продвижения лучших методов проектирования API.
Читайте также:
- Fake-объекты практичнее mock-объектов
- Лучшие практики модульного тестирования
- Тестирование производительности: rust/warp против go/fasthttp
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Allen Helton: How to Automatically Monitor API Performance With Dynamic Testing
