можно ли проводить api тестирование без запуска кода
33 тестера
четверг, 23 июля 2015 г.
Коротко о API и его тестировании
В этом сообщении я постарался собрать информацию, которая может пригодиться тестировщикам, желающим узнать, что такое API. Надеюсь что-то полезное для себя найдут и опытные в тестировании API люди. Ну или хотя бы помогут найти ошибки в моей статье 🙂
Что такое API
Своими словами, API предоставляет нам возможность использовать чужие наработки в своих целях. Впервые я столкнулся с API на примере Windows API. Это набор функций, которые может использовать любое приложение, запущенное на данной ОС. К примеру, оно может использовать стандартные функции для отрисовки интерфейса.
Современные API часто принимают форму веб-сервисов, которые предоставляют пользователям (как людям, так и другим веб-сервисам) какую-то информацию. Обычно процедура обмена информацией и формат передачи данных структурированы, чтобы обе стороны знали, как взаимодействовать между собой.
Форматы передачи данных
Обычные GET запросы способен посылать веб-браузер. Для посылки других типов запросов могут потребоваться скриптовые языки или специальные инструменты (об этом будет ниже).
О H TTP методах можно подробнее почит ать на W iki.
HTTP к оды ответов
Сервер может посылать разные коды в ответ на запросы пользователей. Это могут быть коды ошибок или просто коды, информирующие пользователей о состоянии сервера. Подробное описание можно найти, опять же, на вики.
👨🔧️ Немного про API: от тестового покрытия до QAAPI
Понимание тестового покрытия дает понимание качества продукта, автотесты значительно ускоряют процесс и зачастую делают его более точным, тестирование без доступа к коду показывает возможности продукта с пользовательской стороны. Разберем основные понятия от простого к сложному, ведь хороший инженер QA – постоянно развивающийся инженер QA.
По понятиям
API для QA: что тестируем и как?
API бывает внутренним, когда все компоненты связаны и используются внутри системы, и бывают публичными, когда можно полученную информацию интегрировать с другими приложениями. Чтобы программы корректно работали друг с другом, их API должны соответствовать одному стандарту. Например, существует стандарт архитектуры взаимодействия приложений и сайтов REST.
К сожалению не всегда очевидно, что покрыто тестированием, а что нет. В большой команде проводится много тестов на разных языках, а инженеры QA обладают разной степенью подготовки – может возникнуть вопрос о пересечении тестов между собой.
Выделим две важных задачи:
В основе тестирования всегда лежит бизнес-логика программного продукта, а тестирование API – это интеграционное тестирование, в ходе которого можно отловить ошибки взаимодействия между системами.
API для QA: тест фичи без доступа к коду
Многие особенности приложения невозможно проверить без доступа к коду, особенно если вы только начали обучение или недавно записались на курсы тестировщика. А как тестировать задачи, результат которых нужно ждать от нескольких часов до нескольких дней?
Логично, что удобнее всего подменить константы в программе, но не всякий код позволит так с собой обращаться. Поэтому в результате многочисленных проб и ошибок на простора было создано QAAPI – возможность точечного вмешательства в работу продукта в нужном моменте. Это набор вызываемых и возвращающих ответ методов, которые можно вызвать из браузера. Притом вызывать их можно один из другого.
В каждом проекте свое API и, соответственно, у QAAPI должны быть свои умения, которые и дату назад отмотают, и тестового пользователя зарегистрируют с определенными параметрами, и данные подгрузят, и сервис активируют, и весь нужный пул методов содержат.
Любое QAAPI стоит на трех китах:
Концепция QAAPI проста и в то же время максимально эффективна. Она дает массу преимуществ, подготавливая данные для автоматического тестирования и обеспечивая получение информации о состоянии фичи.
Например, нам нужно проверить, чтобы через 45 секунд после регистрации у нового пользователя появлялось окно с партнерским предложением. Есть метод SetHelloBalTime и URL, принимающий в качестве параметра количество секунд с момента регистрации, когда нужно будет показать пользователю (по его ID) нужное окно.
Выглядело бы это примерно так:
Такой запрос возвращает ответ
Сам класс метода будет таким:
API-помощники в тестировании
Для автоматизации труда инженера QA существует множество различных решений. Рассмотрим два популярных программных продукта, упрощающих работу с QAAPI:
По сути, Swagger представляет из себя документацию, которая генерируется по вашему сервису. Она содержит:
Swagger работает по принципу генерации и при этом неважно, какой фреймворк вы используете.
Есть коды ответов и они также все задокументированы.
Приложение умеет составлять и отправлять запросы, добавлять контрольные точки, параметризовать запросы, создавать разные окружения одним и тем же запросам.
Плюс Postman – графический интерфейс и встроенный компонент Collection Runner, с помощью которого можно запустить наполненную запросами и тестами коллекцию.
Автоматизация тестирования – один из лучших способов проверки качества ПО в текущей версии. И чем чаще и качественнее по уровню проходит обучение инженер QA, тем более современные и мощные инструменты появляются в его арсенале. Образование тестировщика напрямую влияет на его заработок, поэтому важно выбирать максимально качественные обучающие ресурсы. Если вы не новичок в профессии, стоит прокачать английский, а потом перейти к какому-нибудь новому языку программирования. Наиболее эффективным для создания автоматизированных тестов считается Java.
Если вы только начинаете карьерный путь, стоит обратить внимание на факультет тестирования ПО онлайн-академии GeekBrains. Помимо теоретических знаний, здесь вы сможете получить и практические навыки по реализации топовых вариантов автотестов, а также фидбек от опытных наставников и помощь в трудоустройстве.
Можно ли проводить api тестирование без запуска кода
Что пишут в блогах
В этом видео я показал как можно визуализировать покрытие автоматическими тестами для GraphQL api с помощью инструмента Reqover.
Cегодня хочу поговорить с вами на тему комьюнити для тестировщиков.
Как и в любой сфере, среди тестировщиков существует куча различных комьюнити. Раньше они организовывались в скайпе.
Забываю похвастаться статусом книги.
Онлайн-тренинги
Конференции
Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Дейв Вестервельд (DaveWesterveld)
Оригинал статьи
Перевод: Ольга Алифанова
Начиная тестировать API, я не знал о них ничего. За последние несколько лет я многое узнал, и теперь совершенно спокойно использую и тестирую API, но так было не всегда. Когда я начинал, было сложно даже определить, что же делать. Все еще помню, через какую боль я прошел.
На первом курсе университета у нас был профессор математики по кличке «Эйнштейн» – частично из-за его прически, а частично потому, что он делал математику такой же сложной, как теорию относительности. Он начинал решать задачу на доске, а затем говорил «следовательно, очевидно, что» и выводил решение. Мы сидели с озадаченными лицами. Очевидное для него было неочевидно нам, студентам. Нам нужно было знать промежуточные шаги, которые он проскочил, чтобы разобраться, что произошло.
Это частая история. Когда вы узнаете больше, стартовая боль кривой обучения проходит, и становится сложнее и сложнее объяснять что-то тем, кто только начал. Вы начинаете предполагать и делать логические скачки, очевидные для вас, но смущающие новичков в предмете. Продолжая развивать свои знания об API, я хочу записать ряд своих мыслей о тестировании API, пока не стало слишком поздно объяснять это начинающим.
Итак, после этого долгого вступления, вот моя попытка упрощенного руководства для начала API-тестирования.
Выясните конечные точки
Для меня это одна из самых сложных вещей в тестировании API. Как узнать, что там вообще тестировать? Что это API умеет? Если вы работаете с хорошо документированным публичным API, то выяснить это нетрудно, но по моему опыту, большая часть тестирования API проводится на внутренних API, поддерживающих различные части вашего приложения. Как правило, такие API плохо задокументированы (если документация вообще есть). Как же это выяснить?
Конечно, любая имеющаяся внутренняя документация вам поможет, поэтому всегда начинайте с нее, если она есть. И не забудьте, что она может лежать в самых неожиданных местах. К примеру, иногда вам могут помочь комментарии в коде или даже подписи в методе. Документацию можно также найти в сторис или требованиях, которые укажут вам нужное направление.
Еще один отличный источник информации – это люди. В компании есть люди, которые создавали, проектировали, тестировали и/или использовали ваш API? Найдите их и поговорите с ними – они могут быть бесценным источником информации.
И, наконец, можно посмотреть на сетевые вызовы в консоли разработчика, чтобы выявить доступные конечные точки API. Зачастую вызовы API отправляются через сеть, и, разглядывая их через инструменты разработчика, можно многое узнать об их работе.
Все эти источники информации дадут вам неполные и неточные сведения. Наверняка будет то, что вы просто не понимаете, и (особенно поначалу) все будет непонятным и туманным. Но если вы не сдаетесь и продолжаете задавать вопросы и получать обратную связь, то в один прекрасный день осознаете, что вы все поняли и разбираетесь, как API работает.
Авторизацияибезопасность
Авторизация. Аутентификация. Безопасность. Что это и как это работает? С моей точки зрения, процессы авторизации сложны для понимания. Безопасность, конечно, очень важна для работы API, но она может серьезно усложнить его использование. Эта статья сильно разрастется, если я углублюсь в этот вопрос, но хочу все же дать несколько подсказок.
Для начала разберитесь, как вам могут помочь ваши инструменты. Приложения вроде Postman сильно упрощают вопросы авторизации и аутентификации. Они также могут дать вам представление о безопасности вашего API. Покопайтесь в функциональности используемого инструмента, посмотрите, что он предлагает.
Другой момент – когда вас все это раздражает, считайте это полезным опытом. Задавайте вопросы коллегам (и Гуглу). Попытайтесь разобраться, как работает OAuth. Вникните в процесс авторизации. Лично мне изучение авторизации сильно помогло понять работу API и HTTP-протоколов, и это был отличный способ узнать больше о тестировании API.
И напоследок про безопасность – множество вопросов «безопасности» не связано напрямую с техническим тестированием безопасности. Проверка, что разные типы пользователей могут получать только ту информацию, на которую у них есть права, и что все пути отдают правильную информацию – это тоже формы тестирования безопасности. Не забывайте смотреть на ваше API в совокупности.
Учитесь делать, делая
Очень привлекательно потратить много времени на изучение чего-то вроде API-тестирования. Нам кажется, что нам надо знать, что мы делаем, до того, как мы приступим к делу, но я убежден, что лучший способ обучения – практический. Просто попробуйте сделать API-вызовы. Разберитесь, какова конечная точка, и попробуйте ее вызвать. Начните с самого небольшого известного вам участка и используйте его. Пробуя что-то сделать, застревая, разбираясь с этим, вы узнаете то, что вам надо знать про ваш рабочий API. Вы также узнаете, о чем вы не знаете, и что нуждается в изучении, и найдете ресурсы, которые помогут вам разобраться именно с этим вопросом.
Разберитесь с базовой терминологией
У меня есть словарик терминов. Это набор терминов, которые мне пришлось выучить. Возможно, он вам пригодится, но мне кажется важным также выяснить, какие из ваших рабочих терминов вам непонятны, и прояснить этот вопрос. Важно также слушать, какие термины употребляют коллеги, и убедиться, что они вам понятны. Зачастую разные команды и компании используют одинаковые и похожие термины, имея в виду разные вещи. Обращайте внимание на слова, постройте свой словарь. Это упростит задавание вопросов и понимание происходящего.
Что дальше?
Итак, что же делать дальше?
Инструменты тестирования API
Пожалуйста, учтите, что упомянутыми ниже инструментами их спектр для API тестирования не ограничен. Я говорю именно об этих, потому что ими я уже пользовалась.
В следующей секции я покажу, как провести тест API.
Swagger
Согласно официальному сайту, Swagger – это профессиональный инструментарий с открытым исходным кодом, который «упрощает разработку API для пользователей, команд и предприятий».
Я пользовалась Swagger UI, чтобы легко проверить API URL, разобраться в вызовах, а затем добавить их в код моих тестов, но опробовала не все инструменты Swagger. Мне кажется, это простой способ сообщить команде об изменениях API и задокументировать их.
В качестве альтернативы разработчики могут документировать вызовы API в другом формате – обычно списком, как сделано у Twitter. Проблема тут в том, что такая документация может устаревать, и затем надо копаться в коде разработки, чтобы понять, как конкретно выглядит этот вызов. Swagger подтягивает набор вызовов напрямую из кода, поэтому с ним проще работать и поддерживать актуальность документации.
Swagger сделан компанией SmartBear, как и SoapUI, поэтому для тестирования API с их помощью прочитайте следующую секцию.
SoapUI и Postman
s ” a Complete API Test Automation Framework for SOAP, REST and more”. There is an open source version and a professional one featuring more functionality. The API testing part looks like this:
Я взяла изображение с официального сайта, и оно довольно самоочевидно. Кроме того, проект хорошо документирован, что поможет вам разобраться с ним.
Postman – это «платформа для совместной разработки API». Для разработчиков Постман предоставляет автоматическую документацию, и это ликвидирует проблему, при которой разработчики меняют функциональность, а затем забывают сообщить об этом.
Приступить к тестированию API с Postman очень легко. Вы можете создавать запросы REST, SOAP и GraphQL. Инструмент поддерживает множество протоколов авторизации (я расскажу об этом позже) и управление сертификатами. Пожалуйста, посетите официальный сайт, чтобы узнать больше.
Wireshark и Fiddler
Эти два приложения очень полезны для анализа сетевых пакетов. Это мощные программы, которыми в обязательном порядке надо владеть, тестируя безопасность, сеть и производительность, а также проверяя пакеты на микро-уровне. Они помогают увидеть, какие конкретно данные пересылаются через сеть. Однако если вы ищете инструментарий для тестирования API, возможно, стоит выбрать что-то из вышеперечисленных – они более высокоуровневые, и предназначены именно для работы с API.
Несмотря на это, я использовала Wireshark и Fiddler для тестирования API, требовавшего особых сертификатов безопасности, а также для дебага проблем (особенно проблем производительности). Чтобы лучше познакомиться с Fiddler, прочитайте эту статью, а для Wireshark – эту.
Как это автоматизировать?
Если вы хотите добавить тесты API в свой код автоматизации, вышеуказанные инструменты помогут вам в этом. Однако в разных языках программирования различаются способы выполнения таких типов вызовов. К примеру, вот так делается REST-вызов в Python:
# сделать что-то с результатом
response.status_code # это дает вам код статуса, о чем говорилось выше
response.json() # это дает вам json с ответом
Это становится сложнее, если вам нужно добавить параметры, авторизацию, или проанализировать данные, но весь процесс хорошо документирован. Давайте рассмотрим конкретный пример, используя API numbersapi.com.
Результат после выполнения кода выше:
При помощи Python вы можете анализировать данные json, легко извлекая и валидируя текст или число.
Чтобы узнать больше о том, что именно тестировать при проверке API, прочитайте эту статью, которая чудесно объясняет этот вопрос на примере Postman.
А мне какое дело? Сравнение тестирования UI и API
Тестирование UI (пользовательского интерфейса) – наилучший способ имитировать реальное поведение пользователей. Однако мы склонны тестировать через UI то, что уже может быть покрыто тестами API (которые в некоторых компаниях могут выполняться другой группой или командой).
Допустим, разработчик изменил вызов API. Пусть это будет вызов списка избранных фильмов. Теперь представим, что этот вызов не изменился в какой-то части приложения, и в результате пользователь не может найти понравившиеся фильмы. Что происходит в UI-тесте?
UI-тест не сможет найти объект. Это может случиться из-за неверного вызова API, баге в автоматизации, обновлении способа получения объекта, нерабочей кнопки, спрятанного объекта…
Однако при наличии API-теста вы поймете, что вызов ничего не получает в ответ. Если вам нужно проверить что-то вроде результатов поиска, лучше использовать API для проверки всего списка (что можно сделать быстрым сравнением), и убедиться через UI, что результат появляется там, где должен, а не само содержание результата. Вы также должны убедиться, что вызов API верен (и обновить тестовый вызов, если это не так).
Переходим на уровень выше
Вызовы API меньше склонны к переменам по сравнению с объектами UI, и, как правило, перемены имеют другую версию, не затрагивая предыдущие релизы приложения. Это означает, что может быть разумным добавить функциональность проверки того, какая именно версия тестируется.
Тесты API также можно использовать для ускорения UI-тестирования. Наиболее распространенный пример – это метод авторизации. Этот метод обычно становится бутылочным горлом для остальных тестов, и если он падает – вы не можете узнать, что еще падает или успешно проходит, до исправления бага вы беспомощны. Очень важно иметь под рукой тест авторизации, чтобы убедиться, что ваши пользователи способны авторизоваться, но выполнение авторизации через UI при каждом прогоне тестов, для которых она требуется, увеличивает время выполнения этих тестов.
Что же делать? Использовать тестирование API, чтобы пропустить авторизацию. Будьте осторожны, в релизном окружении это будет небезопасным. К примеру, можно настроить уникальные токены (см. пример с SoapUI) с коротким сроком жизни для выполнения этого перехода, и отправлять их вместе с URL, или задать вызов API, настраивающий куки или сессию авторизации.
Если у вас есть другие повторяющиеся зависимые тесты, рассмотрите возможность прогонять API-вызовы, прежде чем переходить к зависящим от этих вызовов тестам. Это серьезно ускорит прогон тестов, и его результаты дадут вам более достоверную информацию о проблеме.
Учитывая вышесказанное, UI-тесты – наилучший способ убедиться, что все корректно работает относительно пользовательского поведения, E2E и интеграционные тесты не должны заменяться тестами API. Используйте их как вспомогательный инструмент, если они не увеличивают сложность и отказы ваших тестов.
И еще на уровень выше: статистика
Другая интересная штука, которую можно делать благодаря API-вызовам – это выяснять информацию о приложении и том, как его использует аудитория. Для глобального анализа и визуализации вызовов можно использовать такие инструменты, как elastic search и kibana, и даже пользоваться искусственным интеллектом для получения выводов об этих вызовах… но это уже другая история.
Стратегия тестирования REST API: что именно вам нужно тестировать?
Общедоступный API, ориентированный на клиента, который делают открытым для конечных пользователей, сам по себе становится продуктом. Если он сломается, это подвергнет риску не только одно приложение, но и целую цепочку бизнес-процессов, построенных вокруг него.
Знаменитая пирамида тестов Майка Кона помещает тесты API на сервисный уровень (интеграционный), что предполагает, что около 20% или более всех наших тестов должны быть сосредоточены на уровне API (точный процент зависит от наших потребностей).
Пирамида тестов
Когда у нас уже есть прочный фундамент из модульных тестов, охватывающих отдельные функции, тесты API обеспечивают более высокую надежность. Они проверяют интерфейс, более близкий к пользователю, но не имеют недостатков тестов пользовательского интерфейса.
Стратегия тестирования API
Основными задачами функционального тестирования API являются:
гарантировать, что реализация API работает в соответствии со спецификацией требований (которая позже становится нашей документацией по API).
предотвратить регрессий между написанным кодом(merge) и релизом.
эндпоинты правильно именованы;
ресурсы и их типы правильно отражают объектную модель;
нет отсутствующей или дублирующей функциональности;
отношения между ресурсами правильно отражаются в API.
Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. После публикации и использования API любые внесенные вами изменения могут внести ошибки в код клиента.(Конечно, когда-нибудь вы сможете опубликовать новую версию API (например, /api/v2 /), но даже в этом случае обратная совместимость скорее всего будет обязательной).
Итак, какие аспекты API мы должны протестировать?
После того как мы проверили соглашение API, мы можем поразмышлять о том, что тестировать. Независимо от того, думаете ли вы об автоматизации тестирования или ручном тестировании, наши функциональные тест-кейсы имеют одинаковый набор тестовых действий. Они являются частью более широких категорий тестовых сценариев и их можно разделить на три потока тестирования.
Этапы тестирования API
Каждый тест состоит из тестовых шагов. Это отдельные атомарные действия, которые тест должен выполнять в каждом потоке тестирования API. Для каждого запроса API тест должен будет выполнить следующие действия:
Проверьте корректность кода состояния HTTP. Например, создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т. Д.
Проверьте полезную нагрузку ответа. Проверьте правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы.
Проверьте заголовки ответа. Заголовки HTTP-сервера влияют как на безопасность, так и на производительность.
Проверьте правильность состояния приложения. Это необязательно и применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить.
Проверьте базовую работоспособность. Если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден.
Категории тестовых сценариев
Наши тест-кейсы делятся на следующие общие группы тестовых сценариев:
Основные позитивные тесты (прохождение успешного сценария по умолчанию)
Расширенное позитивное тестирование с дополнительными параметрами
Негативное тестирование с валидными входными данными
Негативное тестирование с недопустимыми входными данными
Тесты безопасности, авторизации и доступности (которые выходят за рамки этой статьи)
Тестирование успешного сценария по умолчанию проверяет базовую функциональность и критерии приемки API. Позже мы расширим положительные тесты, чтобы включить дополнительные параметры и дополнительные функции.
Тестовые потоки
Давайте разделим и обозначим три вида потоков тестирования, которые составляют наш план тестирования:
Мы выполняем запросы через API и проверяем действия через пользовательский интерфейс веб-приложения и наоборот. Цель этих потоков проверки целостности состоит в том, чтобы гарантировать, что, хотя на ресурсы влияют различные механизмы, система по-прежнему поддерживает ожидаемую целостность и согласованный поток данных.
Пример API и тестовая матрица
Теперь мы можем отобразить все в виде матрицы и использовать ее для написания подробного плана тестирования (для автоматизации тестирования или ручных тестов).
Предположим, что подмножеством нашего API является конечная точка /users, которая включает следующие вызовы API: