[Тестирование IT-систем, Тестирование веб-сервисов] История одного сервера и тестировщика Васи
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Как собрать в прямом эфире 17 000 зрителей? Значит, рецепт такой. Берем 15 актуальных IT-направлений, зовем зарубежных спикеров, дарим подарки за активность в чате, и вуа-ля — крупнейший в Украине и восточной Европе онлайн-ивент готов. Именно так прошла ежегодная мультитул конференция NIXMultiConf.
Под слоганом «айтишникам — от айтишников» эксперты из Украины, Беларуси, России, Великобритании и Германии поделились опытом и рассказали о новинках индустрии. Полезно было всем — дизайнерам, девелоперам, тестировщикам и менеджерам. И теперь делимся инсайтами с вами.
По мотивам докладов экспертов NIX продолжаем серию статей на самые актуальные темы. На этот раз QA Engineer в NIX Сергей Могилевский объясняет, чем отличается тестирование API от UI-тестирования. Спойлер: всё не так страшно, как кажется.
Хотите узнать больше — смотрите конференцию на YouTube-канале.
История одного сервера и тестировщика Васи
Нас пугает новое и неизвестное. Хотя иногда все оказывается не так страшно. В этой статье я расскажу, почему тестировать API на самом деле несложно и как этот скилл поможет стать крутым QA.
Когда в команде дело доходит до тестирования API, начинающий QA теряется — даже смотреть в сторону сервера страшно, не то, что подбирать к нему запросы. И это волнение оправдано. Тестируя UI, невольно становишься пользователем продукта и видишь такой же графический интерфейс, как и потенциальный клиент. Достаточно ввести в нужное поле браузера текст, и тебе выдаст понятную ошибку. При знакомстве с «апишкой» может показаться, что она требует другой стратегии тестирования. На деле же тебе понадобится чуть больше технических знаний:
- понимание клиент-серверной архитектуры;
- принципа работы протокола HTTP;
- знание форматов передачи данных JSON и XML
И, конечно, уверенность в себе.
С первыми пунктами помогу разобраться, а для последнего волшебным пинком пусть будет такой факт: микросервисы правят миром. Монолитная архитектура потихоньку отходит в прошлое. Сегодня все новомодные и облачные решения создают на микросервисной архитектуре. В таком продукте UI могут вообще не предусмотреть, и придется тестировать бекенд.
В монолите бэкенд с фронтендом общается через программный код по единой неизменной схеме. Это как будто ты играешь с напарником в настольный теннис — ваши роли очевидны. В случае с микросервисами каждый из них — отдельный сервер со своей логикой. Один — создает фото, другой — обрабатывает их, третий — хранит, четвертый — передает пользователю. Здесь уже просто отбить мяч бывает недостаточно. Это становится похожим на бейсбол: сначала ты бьешь по мячу, следом — бежишь за ним, чтобы поймать. Так и микросервис может быть одновременно клиентом и сервером по отношению к другим «игрокам».
Допустим, есть сервис, умеющий накладывать фильтры на фото, а другой — хранить файлы. Появляется два варианта их общения:
- сервис с фильтрами «идет» в хранилище фоток, забирает нужный файл и красит фото в сепию. Здесь сервис фильтров — это клиент, а сервис-хранилище — сервер.
- сервис-хранилище берет одну из своих фоток и «несет» сервис-фильтру с целью определить, какой именно фильтр наложен на фотку. Сервис-фильтр такой: «Чувак, это же сепия, что непонятного». Так клиент и сервер поменялись местами.
Чтобы микросервисы друг друга понимали, придумали API (Application Programming Interface) — специальный программный интерфейс. Тестирование помогает убедиться, что программа выполняет поставленную перед ней цель и сможет корректно взаимодействовать с другими программами. Проверять и автоматизировать тесты API можно даже с минимальной теоретической базой. Главное — подобрать правильные инструменты.
Ok, давай тестировать, но чтоб не сложно
Представим 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, лови шпаргалку — полезные материалы по ссылке.
Полный доклад Сергея Могилевского и других спикеров NIX смотри на YouTube-канале. Большей новостей по направлению — на Facebook-странице митапа ThinkQA.
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, Тестирование веб-сервисов] Periskop — инструмент мониторинга исключений (перевод)
- [Тестирование IT-систем, Анализ и проектирование систем, IT-инфраструктура, CRM-системы, ECM/СЭД] Анализ рынка Low-code систем для автоматизации бизнеса
- [Тестирование IT-систем, Java, Apache, Микросервисы] Сервисы с Apache Kafka и тестирование
- [Информационная безопасность, Тестирование веб-сервисов] Атаки на JSON Web Tokens
- [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений, Тестирование игр, Статистика в IT] Обзор рынка труда QA/QC в Москве
- [Высокая производительность, Тестирование IT-систем, Тестирование веб-сервисов] Нагрузочное тестирование выполнять сложно, а инструменты далеки от совершенства. Почему? (перевод)
- [Информационная безопасность, Тестирование веб-сервисов, CTF, Киберпанк] Как стать этичным хакером в 2021 году
- [Тестирование IT-систем, DevOps] Новые задачи из мира непрерывной доставки (перевод)
- [Информационная безопасность, Тестирование мобильных приложений] Проверяем безопасность приложений с помощью Drozer
- [Разработка под iOS, Разработка мобильных приложений, Разработка под Android, Тестирование мобильных приложений] 3 видео для мобильного разработчика
Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_testirovanie_vebservisov (Тестирование веб-сервисов), #_testirovanie (тестирование), #_blog_kompanii_nix (
Блог компании NIX
), #_testirovanie_itsistem (
Тестирование IT-систем
), #_testirovanie_vebservisov (
Тестирование веб-сервисов
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:39
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Как собрать в прямом эфире 17 000 зрителей? Значит, рецепт такой. Берем 15 актуальных IT-направлений, зовем зарубежных спикеров, дарим подарки за активность в чате, и вуа-ля — крупнейший в Украине и восточной Европе онлайн-ивент готов. Именно так прошла ежегодная мультитул конференция NIXMultiConf. Под слоганом «айтишникам — от айтишников» эксперты из Украины, Беларуси, России, Великобритании и Германии поделились опытом и рассказали о новинках индустрии. Полезно было всем — дизайнерам, девелоперам, тестировщикам и менеджерам. И теперь делимся инсайтами с вами. По мотивам докладов экспертов NIX продолжаем серию статей на самые актуальные темы. На этот раз QA Engineer в NIX Сергей Могилевский объясняет, чем отличается тестирование API от UI-тестирования. Спойлер: всё не так страшно, как кажется. Хотите узнать больше — смотрите конференцию на YouTube-канале. История одного сервера и тестировщика Васи Нас пугает новое и неизвестное. Хотя иногда все оказывается не так страшно. В этой статье я расскажу, почему тестировать API на самом деле несложно и как этот скилл поможет стать крутым QA. Когда в команде дело доходит до тестирования API, начинающий QA теряется — даже смотреть в сторону сервера страшно, не то, что подбирать к нему запросы. И это волнение оправдано. Тестируя UI, невольно становишься пользователем продукта и видишь такой же графический интерфейс, как и потенциальный клиент. Достаточно ввести в нужное поле браузера текст, и тебе выдаст понятную ошибку. При знакомстве с «апишкой» может показаться, что она требует другой стратегии тестирования. На деле же тебе понадобится чуть больше технических знаний:
И, конечно, уверенность в себе. С первыми пунктами помогу разобраться, а для последнего волшебным пинком пусть будет такой факт: микросервисы правят миром. Монолитная архитектура потихоньку отходит в прошлое. Сегодня все новомодные и облачные решения создают на микросервисной архитектуре. В таком продукте UI могут вообще не предусмотреть, и придется тестировать бекенд.  В монолите бэкенд с фронтендом общается через программный код по единой неизменной схеме. Это как будто ты играешь с напарником в настольный теннис — ваши роли очевидны. В случае с микросервисами каждый из них — отдельный сервер со своей логикой. Один — создает фото, другой — обрабатывает их, третий — хранит, четвертый — передает пользователю. Здесь уже просто отбить мяч бывает недостаточно. Это становится похожим на бейсбол: сначала ты бьешь по мячу, следом — бежишь за ним, чтобы поймать. Так и микросервис может быть одновременно клиентом и сервером по отношению к другим «игрокам». Допустим, есть сервис, умеющий накладывать фильтры на фото, а другой — хранить файлы. Появляется два варианта их общения:
Чтобы микросервисы друг друга понимали, придумали API (Application Programming Interface) — специальный программный интерфейс. Тестирование помогает убедиться, что программа выполняет поставленную перед ней цель и сможет корректно взаимодействовать с другими программами. Проверять и автоматизировать тесты API можно даже с минимальной теоретической базой. Главное — подобрать правильные инструменты. Ok, давай тестировать, но чтоб не сложно Представим 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, лови шпаргалку — полезные материалы по ссылке. Полный доклад Сергея Могилевского и других спикеров NIX смотри на YouTube-канале. Большей новостей по направлению — на Facebook-странице митапа ThinkQA. =========== Источник: habr.com =========== Похожие новости:
Блог компании NIX ), #_testirovanie_itsistem ( Тестирование IT-систем ), #_testirovanie_vebservisov ( Тестирование веб-сервисов ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:39
Часовой пояс: UTC + 5