Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова
API (программный интерфейс приложения) – это набор вызовов, при помощи которых приложение общается со своими частями. К примеру, так общается пользовательский интерфейс с компонентом ПО (удаленным или локальным сервером), который осуществляет необходимые операции, позволяющие приложению функционировать.
Если вам интересно, как это выглядит в веб-приложении, то можно просто посмотреть на вкладку «Сеть» в панели инструментов разработчика. вы увидите, что при взаимодействии с веб-сайтом в фоновом режиме осуществляется множество вызовов.
Вкладка «Сеть» в Chrome для сайта google.com
Если кликнуть на вызов в левой части панели, в правой части появится информация о нем. URL запроса – это адрес, которого пытается достичь вызов.
Для веб-вызовов используется два основных метода – GET (для получения информации с сервера) и POST (для отправки информации на сервер). Узнать больше о других методах можно здесь.
Следующее поле тоже очень важно. Это сообщение, которое сервер отправляет после выполнения вызова. В этом случае это 307 (перенаправление). Узнать, что значат другие коды статусов, можно по этой ссылке, если вы кошатник, или этой, если предпочитаете собак.
Для отправки информации между устройствами используется два широко применяемых протокола – SOAP (простой протокол доступа к объектам), отправляющий информацию в формате XML, и REST (передача состояний представления), передающий информацию в различных форматах – это может быть json, html, xml, и чистый текст (см. статью, поясняющую их особенности).
Инструменты тестирования 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, и даже пользоваться искусственным интеллектом для получения выводов об этих вызовах… но это уже другая история.
Тестирование API
Введение: Что такое API
В широком смысле слова API (Application Programming Interface) это метод который приложение предоставляет внешним пользователям для коммуникации с ним. Обычно через Интернет.
Это может быть взаимодействие с сервером приложения на смартфоне, между компьютерами или другими устройствами.
API применяются там где невозможна или нежелательна непосредственная интеграция с исходным приложением, то есть практически везде.
Крупные интернет-компании обычно предоставляют (платно или бесплатно) доступ к API своих сервисов.
Где применяют API
Сейчас будет несколько абстрактных примеров просто для понимания сути.
Конкретные примеры работы с API я разбираю в учебнике
Пример №1:
Если Вы хотите разместить на своём сайте яндекс-карты Вам не нужно устанавливать программы от Яндекса, достаточно послать несколько запросов и Яндекс передаст необходимую информацию.
Пример №2:
Предположим, что Вы создали сайт vk2.com. Вы хотите, чтобы вебмастера могли добавить на свои сайты возможность комментировать записи используя учётную запись vk2, но раскрывать или раздавать свой код не хотите.
Чтобы обойти эту проблему Вы выкладываете в публичном доступе правила, по которым вебмастера могут обращаться к vk2, чтобы получить комментарии.
Формат этих сообщений это обычно либо JSON либо XML. О них мы поговорим позже.
Повторим для закрепления сути: Смысл в том, что сайт написанный на любом языке, поддерживающем HTTP запросы, не посылает на сервер никаких PHP/C/Python команд, а общается ним с помощью запросов, описанных в API.
Если вам интересен реальный пример работы с API рекомендую статью Работа с API GitHub
Endpoint
Адрес, на который посылаются сообщения называется Endpoint.
Обычно это URL (например, название сайта) и порт. Если я хочу создать веб сервис на порту 8080 Endpoint будет выглядеть так:
Если моему Web сервису нужно будет отвечать на различные сообщения я создам сразу несколько URL (interfaces) по которым к сервису можно будет обратиться. Например
https://andreyolegovich.ru:8080 /resource1/status
https://andreyolegovich.ru:8080 /resource1/getserviceInfo
https://andreyolegovich.ru:8080 /resource1/putID
http://andreyolegovich.ru:8080 /resource1/eventslist
https://andreyolegovich.ru:8080 /resource2/putID
…
Как видите у моих эндпойнтов (Enpoints) различные окончания. Такое окончание в Endpoint называются Resource, а начало Base URL.
Такое определение Endpoint и Resource используется, например, в SOAP UI для RESTful интерфейсов
Endpoint = Base URL + Resource
Понятие Endpoint может использоваться в более широком смысле. Можно сказать, что какой-то определённый роутер или компьютер является Endpoint. Например, в понятии Endpoint Management под Endpoint имеют в виду конечное устройство. Обычно это понятно из контекста.
Также следует обратить внимание на то, что понятие Endpoint выходит за рамки RESTful и может использовать как в SOAP так и в других протоколах.
Термин Resource также связан с RESTful, но в более широком смысле может означать что-то другое.
На программистском сленге Endpoint иногда называют ручкой.
Спецификация
После того все эти интерфейсы созданы, их необходимо описать. Нужен документ из которого будет понятно
Этот документ должен быть доступен программистам с обеих сторон, иначе они просто не смогут договориться и реализовать работающий Web сервис.
HTTP методы
Вернёмся к первому пункту списка, а именно к тому, что такое методы.
В протоколе HTTP предусмотрено несколько способов отправить запрос на один и тот же Endpoint.
Про их свойства можно почитать здесь.
Когда мы знаем какие методы с какими Enpoint можно использовать составить запросы не составит труда.
GET http://andreyolegovich.ru:8080 /resource1/status
GET http://andreyolegovich.ru:8080 /resource1/getserviceInfo
PUT http://andreyolegovich.ru:8080 /resource1/putID
GET http://andreyolegovich.ru:8080 /resource1/eventslist
POST http://andreyolegovich.ru:8080 /resource1/eventslist
PUT http://andreyolegovich.ru:8080 /resource2/putID
…
Таким образом простейший запрос состоит из метода и Enpoint
Request = Method + Endpoint
Пример API
Чтобы узнать количество велосипедистов в городе нужно отправить GET запрос на https://topbicycle.ru:/bicyclists/$город
GET https://topbicycle.ru /bicyclists/helsinki
Получив такой запрос сайт вернёт число велосипедистов в Хельсинки.
Попробуйте вставить эту строку в браузер.
Это очень простые уроки для самых начинающих. Буду рад любым отзывам и предложениям в комментариях.
Тестирование API без документации
Если Вам по какой-то причине предстоит проделать эту неблагодарную работу, определетесь, насколько всё плохо. Какая у Вас есть информация об объекте тестирования.
Известно ли какие порты для Вас открыты? Знаете ли Вы нужные endpoints?
Сканирование портов
Перебор запросов
Если Вам известен нужный порт и соответствующий endopoint переберите все возможные HTTP методы. Начните с наиболее очевидных:
В худшем случае, когда ни порт ни endpoints неизвестны Вам, скорее всего придётся перебирать все открытые порты и генерировать endpoints, которые подходят по смыслу.
Разработчики обычно не особо заморачиваются и закладывают минимально-необходиму информацию. Так что включите воображение и попробуйте придумать endpoints опираясь на бизнес логику и принятые в Вашей компании стандарты.
Если ни endpoints ни бизнес логика Вам неизвестны, то у меня есть подозрение, что Вы тестируете API с не самыми хорошими намерениями.
Инструменты для тестирования
Существует множество инструментов для тестирования. Здесь Вы можете познакомиться с одними из самых популярных: Python и SOAP UI.
О работе с REST API на Python вы можете прочитать в статье «REST API с Python»
Тестирование API за 10 минут
Что такое API?
API расшифровывается как “интерфейс прикладного программирования” или “интерфейс программирования приложений”.
Он позволяет осуществлять связь и обмениваться данными между двумя отдельными модулями программы. Система программного обеспечения, реализующая API, содержит функции/подпрограммы, которые могут быть выполнены с помощью другого программного обеспечения.
Что подразумевает тестирование API?
Тестирование API полностью отличается от тестирования графического интерфейса и в основном концентрируется на слое бизнес-логики архитектуры программного обеспечения. GUI в API тестировании практически не нужен.
Вместо стандартных видов ввода пользовательских данных (заполнение форм) здесь для передачи данных используется программное обеспечение.
Для API тестирование нам потребуется само тестируемое приложение и приложение для работы с API. Также потребуется написать собственный код для работы с API.
Настройка среды тестирования API
Тестирование API отличается от других видов отсутствием пользовательского интерфейса, следовательно, мы должны настроить с необходимым набором параметров среду тестирующую API, а затем проанализировать результаты теста.
База данных и сервер должны быть настроены в соответствии с требованиями приложения. После завершения настройки должна быть вызвана API функция для проверки этих настроек.
Выходные данные API
Давайте рассмотрим пример каждого типа.
Любой тип данных
Пример: Существует функция API, который должен добавить два целых числа.
Long add(int a, int b)
В качестве входных параметров должны быть приведены числа. На выходе должна быть сумма двух целых чисел. Полученный результат должен быть сравнен с ожидаемым результатом.
Вызов должен быть примерно таким:
При превышении предела должно быть обработано исключение.
Статус (true или false)
Рассмотрим ниже функции API
Они возвращают какое-либо значение, такое как True (в случае успеха) или False (в случае ошибки), в качестве выходного.
Более полный тест впоследствии может вызвать функцию или скрипт, а затем проверить изменения в базе данных или обновление графического интерфейса.
Вызов другой функции API
В этом случае мы вызываем одну из функции API, которая в свою очередь, будет вызывать другую функцию.
Например, первая функция API может быть использована для удаления указанной записи в таблице и эта функция в свою очередь вызывает другую функцию, чтобы обновить базу данных.
Разница API-тестированием и Unit-тестированием
| Unit-тестирование | API-тестирование |
| · Выполняется разработчиками | · Выполняется тестировщиками |
| · Тестируются отдельные модули | · Тестируется end-to-end функционал |
| · Разработчик имеет доступ к исходному коду | · Тестировщик не имеет доступа к исходному коду |
| · Возможно тестирование UI | · Тестируется только API |
| · Тестируется только базовый функционал | · Тестируется весь функционал |
| · Ограничен в возможностях | · Широкие возможности |
| · Запускается до заливки на SCV | · Запускается после билда |
Виды тестов в тестировании API:
Лучшие практики тестирования API:
Типы ошибок, которые обнаруживаются при API тестировании:
Инструменты для тестирования API
Проблемы в тестировании API
Вывод
API состоит из множества классов / функций / процедур, которые представляют собой слой бизнес-логики. Если API не проверяется должным образом, то это может вызвать проблемы не только в применении API, но и в вызывающем приложении.
Стратегия тестирования 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:
