33 тестера
четверг, 23 июля 2015 г.
Коротко о API и его тестировании
В этом сообщении я постарался собрать информацию, которая может пригодиться тестировщикам, желающим узнать, что такое API. Надеюсь что-то полезное для себя найдут и опытные в тестировании API люди. Ну или хотя бы помогут найти ошибки в моей статье 🙂
Что такое API
Своими словами, API предоставляет нам возможность использовать чужие наработки в своих целях. Впервые я столкнулся с API на примере Windows API. Это набор функций, которые может использовать любое приложение, запущенное на данной ОС. К примеру, оно может использовать стандартные функции для отрисовки интерфейса.
Современные API часто принимают форму веб-сервисов, которые предоставляют пользователям (как людям, так и другим веб-сервисам) какую-то информацию. Обычно процедура обмена информацией и формат передачи данных структурированы, чтобы обе стороны знали, как взаимодействовать между собой.
Форматы передачи данных
Обычные GET запросы способен посылать веб-браузер. Для посылки других типов запросов могут потребоваться скриптовые языки или специальные инструменты (об этом будет ниже).
О H TTP методах можно подробнее почит ать на W iki.
HTTP к оды ответов
Сервер может посылать разные коды в ответ на запросы пользователей. Это могут быть коды ошибок или просто коды, информирующие пользователей о состоянии сервера. Подробное описание можно найти, опять же, на вики.
От шока до принятия: пять стадий тестирования API
Привет, я Сергей Могилевский, QA Engineer в NIX. Уже пять лет занимаюсь тестированием. Постоянно учусь сам и обучаю других. Сейчас — тимлид на проекте. Решаю самые сложные технические задачи и занимаюсь менеджментом подопечных. Делюсь опытом на внутренних тренингах и конференциях. На NIX MultiConf выступал трижды.
Хочу рассказать о важности тестирования API. Засилье микросервисной архитектуры в современных сервисах вынуждает нас адаптироваться к новым требованиям QA. Неотъемлемый шаг этой адаптации — умение тестировать продукт без использования UI-интерфейса. Это не так сложно, как кажется.
Нас пугает новое и неизвестное. Хотя иногда все оказывается не так страшно. В этой статье я расскажу, почему тестировать API не сложно и как этот скил поможет стать крутым QA.
Когда в команде дело доходит до тестирования API, начинающий QA теряется — даже смотреть в сторону сервера страшно, не то что подбирать к нему запросы. И это волнение оправдано. Тестируя UI, невольно становишься пользователем продукта и видишь такой же графический интерфейс, как и потенциальный клиент. Достаточно ввести в нужное поле браузера текст, и тебе выдаст понятную ошибку. При знакомстве с апишкой может показаться, что она требует другой стратегии тестирования. На деле же тебе понадобится чуть больше технических знаний:
И, конечно, уверенность в себе.
Зачем тестировать API
С первыми пунктами помогу разобраться, а для последнего волшебным пинком пусть будет такой факт: микросервисы правят миром. Монолитная архитектура потихоньку отходит в прошлое. Сегодня все новомодные и облачные решения создают на микросервисной архитектуре. В таком продукте UI могут вообще не предусмотреть, и придется тестировать бэкенд.
В монолите бэкенд с фронтендом общается через программный код по единой неизменной схеме. Это как будто играешь с напарником в настольный теннис — ваши роли очевидны. В случае с микросервисами каждый из них — отдельный сервер со своей логикой. Один создает фото, другой обрабатывает их, третий хранит, четвертый передает пользователю. Здесь уже просто отбить мяч недостаточно. Это становится похожим на бейсбол: сначала бьешь по мячу, затем бежишь за ним, чтобы поймать. Так и микросервис может быть одновременно клиентом и сервером по отношению к другим «игрокам».
Допустим, есть сервис, который умеет накладывать фильтры на фото, а другой — хранить файлы. Появляется два варианта их общения:
Чтобы микросервисы друг друга понимали, придумали API (Application Programming Interface) — специальный программный интерфейс. Тестирование помогает убедиться, что программа выполняет поставленную перед ней цель и сможет корректно взаимодействовать с другими программами. Проверять и автоматизировать тесты API можно даже с минимальной теоретической базой. Главное — подобрать правильные инструменты.
Представим QA Васю, которому только что сказали проверить функционал по созданию пользовательских карточек в софте для больниц. В продукте не предусмотрен UI, данные приходят из сторонней системы. То есть сервис заточен под то, чтобы одна программа использовала другую. До этого он всю карьеру проводил исключительно мануальные UI-тесты. У Васи первая стадия на этапе тестирования — шок. Перед ним ни одной знакомой кнопки и полей.
Вася, выдыхай. Вот тебе самый распространенный инструмент для тестирования апишек — Postman. Программа позволяет в понятном для нас виде оформить запрос и передает его серверу на доступном ему языке. В Postman будем вписывать все дальнейшие шаги.
Чтобы запросить информацию у сервера, понадобится протокол HTTP — формат передачи гипертекста в клиент-серверной архитектуре. Типы запросов бывают разные. Иногда клиент хочет что-то попросить или отправить серверу, иногда удалить с него информацию. Так появились методы HTTP-запросов. Самые распространенные: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH. Метод определяет действие относительно сервера.
Итак, выбираем путь, по которому отправим запрос:
То, что хотим сообщить серверу, — тело запроса. Штука опциональная. Ключевая для сервера информация отображается в методе передачи запроса. Возвращаясь к нашему примеру eHealth-программы, в строке «Путь» пишем нужную ссылку, а в теле указываем информацию о медицинской карточке: имя, фамилию, возраст пациента и диагноз.
Заголовок помогает серверу правильно расшифровать сообщение. Иногда он не связан с телом запроса или его вообще нет. Указывая в заголовке Accept, мы даем серверу понять, какие данные готовы принять в ответ. Если устроит любая информация, в заголовке должно быть значение «* / *».
Отрицание
Postman выдал набор текста, кавычек, запятых и прочие символы. Вася ничего не понимает, злится. Он переживает отрицание — пока мало верит, что из этого получится нечто полезное.
К счастью, у протокола HTTP есть описание не только запросов, но и ответов сервера. 415 — это код состояния. Сервер говорит, что получил данные, которые не умеет читать. Существует множество кодов состояний для разных ситуаций. Ответ 200 ОК — признак успешного запроса. Код 404 известен всем пользователям интернета и значит, что ресурс не найден. Останавливаться на status codes не буду. Их все можно загуглить.
Что же Вася сделал не так? Скорее всего, он не подумал о правильной «упаковке» документа. Для хранения и передачи данных используют JSON и XML — полностью взаимозаменяемые форматы. Трудно передать большой массив информации только через текст. Словами, конечно, это можно было бы сделать, если бы данные не читал компьютер. Он заранее должен знать формат и типы данных, как их найти в системе и работать с ними. Нельзя рассылать XML или JSON всем серверам и думать, что тебя поймут. Формат принимаемых данных разработчики прописывают при создании программы.
Вася погуглил и выяснил, что его сервер умеет общаться на JSON, поэтому вновь по тому же адресу в нужном формате отправляет запрос. Успех! Сервер ответил очередным набором символов, но благодаря Postman их можно перевести.
Подытожим: протокол HTTP определяет формат общения клиента и сервера. Чтобы отправить HTTP-запрос, нужен специальный софт (Postman, а также можно попробовать Insomnia REST Client, HTTPie или другую программу из списка). Клиент, наш Вася, отправляет сообщение и принимает соответствующий ответ. Общение с сервером происходит в одном из форматов — JSON/XML. Полученные данные расшифровывает софт.
Чтобы автоматизировать API-тест, тебе нужно освоить язык программирования: Python, Java, С# или любой другой понравившийся либо необходимый в проекте. И тут Вася такой: «Автоматизация? Ой, давайте нет? Там же придется написать тонну кода. Я никогда так не мог и не смогу. На тестировании остановимся, ОК?».
На самом деле, уложиться можно в несколько строчек. Для запуска простого теста достаточно освоить базу языка. Можно еще поискать какую-нибудь библиотеку для написания HTTP-запросов. В любом случае изучение программирования будет существенным вложением в вашу профессиональную копилочку.
Не стоит размениваться несколькими часами свободного времени ради того, чтобы открыть себе путь в автоматизацию чего бы то ни было. Сначала будет сложно, но уверяю, вскоре вы ощутите большой скачок своего технического развития. В будущем изучение других инструментов уже не даст такого ощущения победы над собой.
Принятие
Мне уже не надо уговаривать Васю понять преимущества тестирования и автоматизации API. В моей команде из 16 человек пять — тестируют апишки веб-приложения. Думаю, это явный признак востребованности навыков. У любого сайта или приложения с использованием современных технологий сложный бэкенд. С большой долей вероятности разработчик выберет микросервисную архитектуру для его воплощения. Поэтому без теста апишек не обойтись.
Секрет в том, что. секрета нет
Никакой магии не будет. Тестирование UI-интерфейса, дополненной реальности, баз данных, API — подходы к проверке функционала обычно одинаковые. Продумывание тест-кейсов и ведение чек-листов почти не отличаются от стратегии в обычных мануальных UI-тестах. В случае с API нужны описанные выше hard skills и дополнительные инструменты.
В профессии QA, если ты чего-то не умеешь, то получаешь меньше предложений на рынке. Ты ограничиваешь свои возможности и карьерный рост, тебя не позовут в какую-то движуху. А в движе хочется быть всем, правда? Вот и я об этом.
Чтобы освоить тестирование, не нужно годами учить матчасть. Достаточно нескольких месяцев упорной практики. В качестве помощи подкину свою шпаргалку по тестированию API — ищи полезные материалы по ссылке. Базовая теория, задачи, инструменты, библиотеки и фреймворки — все, что поможет тебе погрузиться в тему и продолжить обучение самостоятельно. Дерзай!
Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно. І підписуйтеся на Telegram-канал редакції DOU
Топ 11 инструментов для тестирования API
Для чего нужно тестирование API?
Подводные камни тестирования API
Самый большой подводный камень – недопонимание в команде. Тестировщики думают, что разработчики должны сами протестировать API при его написании. Разработчики же, в свою очередь, убеждены, что тестирование API — прямая обязанность тестировщиков.
Также не все тестировщики понимают, как проводить тестирование API, поэтому они просто сосредотачиваются на тестировании UI.
Роль AI и машинного обучения в тестировании API
Для уменьшения сложности тестирования API, некоторые разработчики создали инструменты, которые используют AI для преобразования тестов UI в тесты API. Эти инструменты словно снайперы, которые используют машинное обучение для автоматического поиска шаблонов и связей между различными микросервисами по мере взаимодействия пользователя с ними.
С усовершенствованием таких утилит становится очевидным, что тестирование API будет становиться все проще и проще.
Я еще не встречал таких инструментов в открытом доступе, однако это не повод забыть про тестирование API, потому как приобретенный опыт поможет вам в будущем при освоении более продвинутых инструментов.
👨🔧️ API для QA: учимся тестированию ПО без доступа к коду
Юлия Ильюшкина
Использование Postman
Postman использует протокол HTTP для взаимодействия между серверами. Он доступен как в веб-версии, так и в виде настольного приложения с графическим интерфейсом.
· Создание и отправка запросов
· Изменение параметров запросов.
· Сохранение созданных запросы в коллекции и папках.
· Запуск автоматических тестов на основе коллекций п ри помощи Collection Runner.
· Изменение окружения для одинаковых запросов.
· Добавление контрольных точек к вызову API.
Создание метода Postman
Стоит отметить, что тестирование при помощи API возможно только при наличии самого API и документации от разработчика. Это позволит точно понимать функции продукта без противостояния инженера QA и программиста на вечную тему: «Это баг!» & «Нет, это фича!».
В статье для начинающих мы рассмотрим ручное тестирование по 4 основным запросам:
· POST – создание ресурса на сервисе, т. е. отправку данных на сервер.
· GET – получение ресурса с сайта.
· PUT – обновление данных на сервере.
· DELETE – удаление ресурса с сайта.
При работе с Postman стоит знать о статусах и классах состояний сервера:
Классы состояний сервера
В примерах рассмотрим статус 200 ОК, который информирует об успешности выполнения операции, т.е. пользователь когда получает ожидаемый результат – страницу с запрашиваемой информацией.
Примеры запросов в Postman для быстрого обучения тестировщика
После запуска в Postman стоит создать папку с коллекцией запросов. Для этого нужно во вкладке Collections нажать на New Collection.
Указываем название коллекции.
Создаем запрос нажатием на Add requests.
Рассмотрим регистрацию пользователя, поэтому указываем соответствующее название и нажимаем на Save to [Collections name].
Указываем url тестируемого сайта.
Прописываем название соответствующего API, в данном случае api/register.
Во вкладке Body выбираем raw.
Далее выбираем формат текста JSON.
Нажатием на Send отправляем данные.
В соответствующем поле видим ожидаемый результат, указанный в документации и статус 200 ОК.
Выполним запрос на получение данных о созданном пользователе, выбираем GET.
Указываем ссылку на API и после отправления смотрим на полученный результат, соответствующий ожидаемому.
Попробуем обновить данные пользователя, для этого создаём update_user.
Указываем ссылку с url и API, открываем окно для кода.
Отправляем новые данные.
В результате указана обновленная информация и время, когда были внесены изменения. Дополнительно успешность операции подтверждает ответ 200 от сервера.
DELETE
Создаём запрос на удаление пользователя.
Указываем полную ссылку на страницу пользователя и отправляем.
Получаем от сервера в ответ статус 204 No Content, информирующий об успешности запроса, но без содержимого, т. е. данные были успешно удалены.
Документация, необходимая тестировщику для обучения
Ознакомиться со всеми функциями инструмента можно в документации от разработчиков Postman. В информационном центре представлена инструкция по составлению ручных и автоматизированных запросов, настройке коллекций, использованию cookies, сбору данных, а также по составлению запросов для устранения ошибок и прочее.
Разобраться с нюансами профессии QA и QC, а также получить необходимые знания и изучить инструменты можно на курсе по тестированию ПО от GeekBrains. Вебинары проводят практикующие специалисты, которые не только помогут студентам стать тестировщиками с нуля, но и подскажут, как составить резюме и получить работу.
👨🔧️ Немного про 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. Помимо теоретических знаний, здесь вы сможете получить и практические навыки по реализации топовых вариантов автотестов, а также фидбек от опытных наставников и помощь в трудоустройстве.
