Коды ошибок постман

Автор: Кристин Джеквони (Kristin Jackvony)

Оригинал статьи

Перевод: Ольга Алифанова.

Если вы хоть раз делали REST-запрос или изучали раздел инструментов разработчика в браузере, то наверняка видели код ответа из трех цифр, возвращенный в ответ на HTTP-запрос. Давайте поговорим о различных типах кодов ответа, которые можно получить в процессе тестирования API, и том, что они означают.

Ответы 100

Ответы уровня 100 означают, что запрос должен продолжаться. Наиболее частый тип такого ответа – это просто-напросто 100 Continue. Это может использоваться при объемных запросах, давая серверу возможность остановить большой запрос до того, как будет передан слишком большой объем данных. Возможно, при тестировании вашего API вы с этим не столкнетесь – сервер продолжит отвечать, завершит этот процесс «за кулисами» и выдаст ответ-200.

Ответы 200

Ответы уровня 200 обозначают успех запроса. Наиболее распространенный ответ – это 200 OK, который просто означает, что все прошло как ожидалось. Вот другие примеры запросов этого уровня:

201 Created – такой ответ означает, что в результате запроса создан некий новый ресурс. К примеру, GET-запрос может создать запись в логе, демонстрирующую дату, время и содержание запроса.

202 Accepted – этот ответ значит, что запрос был принят, но еще не завершен. Например, это изменение базы данных, которое нуждается в одобрении перед тем, как повлиять на базу непосредственно.

204 No Content – это значит, что запрос был успешно обработан, и не вернул никаких данных. Этот ответ может прийти на PUT-запрос, когда содержание изменилось, но разработчик не видел необходимости отдавать в ответе какие-то данные. Ответ 200 OK тоже может не возвращать данные, если так решил разработчик, но 204 не возвращает их никогда.

Ответы 300

Ответы уровня 300 говорят о перемещении ресурса. Наиболее частый из таких ответов – это 301 Moved Permanently. Этот ответ должен включать новый URL в заголовке, чтобы клиент понимал, куда в следующий раз обращаться с запросом.

Ответы 400

Ответы уровня 400 обозначают, что с запросом было что-то не так. Наиболее частый из них – 400 Bad Request, обычно применяемый, когда запрос неверно сформулирован или по какой-то причине неправилен. К примеру, в нем отсутствуют необходимые данные, или произошла ошибка валидации этих данных. Другие распространенные варианты ответов-400:

401 Unauthorized – обычно отдается, если у клиента нет соответствующей аутентификации для запроса, к примеру, токена JWT или куки.

403 Forbidden – отдается, если у клиента есть аутентификация, но нет прав на просмотр ресурса. К примеру, пользователь залогинен и может запрашивать свои данные, но не может запрашивать чужие.

404 Not Found – возвращается, если клиент запрашивает специфический ресурс, а сервер не может его найти. Например, запрашивается пользователь с ID 100, отсутствующий в базе данных.

409 Conflict – отдается, если запрос заставляет данные конфликтовать друг с другом. К примеру, клиент пытается осуществить POST-запрос для создания ресурса с ID, который уже используется.

Ответы 500

Ответы уровня 500 значат, что что-то пошло не так на серверной стороне. Чаще всего встречается ответ 500 Internal Server Error, использующийся для обозначения разнообразных проблем. Например, запрос пытался добавить запись в базу данных, которая не может обработать такую запись, потому что в ней слишком много символов, или у записи неверный тип. Другие ответы уровня 500 могут быть такими:

502 Bad Gateway – происходит, если сервер, отвечающий на запрос, должен сделать запрос к другому серверу, а другой сервер возвращает невалидный ответ.

503 Service Unavailable – такой ответ возвращается, если отвечающий сервер по какой-то причине недоступен. Он обычно более полезен, нежели общий ответ 500, потому что сигнализирует, что проблема с доступностью сервера, а не с базой.

Теперь, когда мы знаем, что значат коды ответов, давайте посмотрим на них предметно в нашей коллекции Postman PetStore! Если вы еще не создали, см. предыдущую статью. Кликните на первом запросе в коллекции: Add Pet. Под URL запроса нажмите на «тесты». В правой стороне окна будет список сниппетов кода, которые можно использовать для создания правил. Проскролльте список вниз, пока не найдете сниппет «Status code: Code is 200», и нажмите на него. Это автоматически добавит правило в поле теста, который выглядит вот так:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

Секция «Status code is 200» – это название вашего теста. Секция «pm.response.to.have.status(200)» – это ожидаемый результат.

Нажмите кнопку «Save», а затем «Send». В нижней части страницы вы увидите секцию «Test Results» с «1/1» после названия секции. Это значит, что был запущен один тест, и один тест прошел успешно. Если нажать на ссылку «Test Results», вы увидите «PASS» и «Status code is 200» в секции ответа. Вы успешно добавили правило к вашему запросу!

Давайте посмотрим, как выглядит упавшее правило. Чтобы заставить его упасть, просто измените тело правила на:

pm.test("Status code is 202", function () {
    pm.response.to.have.status(202);
});

Теперь мы ожидаем ответа 202, а не 200. Снова запустите запрос, и вы увидите «0/1» рядом со ссылкой «Test Results». Нажмите на ссылку, и в секции ответа вы увидите «FAIL» и «Status code is 202». Это значит, что тест по имени «Status code is 202» упал.

Снова поменяйте тест, чтобы он ожидал ответа 200, и добавьте правило ко всем запросам коллекции, кроме запроса «Verify Delete Pet». Этот запрос ищет запись, которая больше не существует, поэтому там мы не ожидаем ответа 200. Вместо этого мы должны получить 404 Not Found. Давайте добавим это ожидание в секцию тестов:

pm.test("Status code is 404", function () {
    pm.response.to.have.status(404);
});

Нажмите на кнопку «Save» и сохраните тест.

Если вы прогоните этот запрос до запроса Delete Pet, то тест упадет, потому что животное с ID 100 все еще существует. Но если вначале запросить Delete Pet, а затем Verify Delete Pet, то тест будет пройден успешно, потому что животного с ID 100 больше нет в базе данных.

Теперь у нас есть правила для всех наших запросов. Давайте запустим прогон всей коллекции! Наведите курсор на название коллекции Pet Store, и нажмите на шеврон >, который появится справа. Кликните по кнопке «Run», и откроется Collection Runner. Нажмите на имя вашей коллекции, а затем – на кнопку «Run Pet Store». Вы увидите, как запускаются (и успешно выполняются) все ваши тесты, причем очень быстро! Окно результатов будет выглядеть примерно так:

В верхней части окна вы увидите, что шесть ваших тестов прошло успешно, и ни один не упал. Вы увидите названия всех созданных запросов, имена тестов для каждого запроса, и индикатор «PASS».

Обсудить в форуме

Once you send the request, API sends the response. A response is a message the server receives in return for a Request we send. When we send the request, then server accepts that request in and sends back a packet of the requested information, which is called the response. Each response depends on the sent request.

The server responds differently for every request, and it will be good if we take out some info from all of the server responses. It provides a user-friendly interface to see multiple pieces of information from all of the responses easily.

The postman response interface has multiple options. Let’s see these options one by one:

Response Status and Information

Enter the URL www.javatpoint.com and see the response:

On the top right corner of the response box, we can see the Status, Time, and Size of the code.

Status Code

A status code defines the status of the request. On entering URL, a mistake can be typed in the URL, or there may be a server-side problem. Status code is used to know about what went wrong and where you made a mistake. There are different status codes, and each of the status codes has different meanings.

Let’s see some standard status codes:

200: This code is used for a successful request.

201: For a successful request and data was created.

204: For empty response.

400: This is used for Bad Request. If you enter something wrong or you missed some required parameters, then the request would not be understood by the server, and you will get 400 status code.

401: This is used for Unauthorized Access. If the request authentication failed or the user does not have permissions for the requested operations, then you will get a 401 status code.

403: This is for Forbidden or Access Denied.

404: This will come if the Data Not Found.

405: This will come if the method not allowed or if the requested method is not supported.

500: This code is used for Internal Server Error.

503: And this code is used for Service Unavailable.

Time

Time is the duration between the sent request time and the received response time. Means, this is the duration which the response took after we sent the request and received the response.

This is very useful sometimes because many projects have a Service Level Agreement (SLA). The time shown here is not the actual time that the request will take. It is just approximate time, but you can consider this as an actual time.

Size

Size is the size of the response when it is processed within memory. This response size includes the size of response, cookies, headers, and everything that has been transmitted along with the response.

Response Body

A Response body is the body of the response, which actually contains the response content that has been sent from the server. In this section, you can see the web page code is sent to us as a response.

In this box, there are three ways to see the response in the response body:

• Pretty
• Raw
• Preview

Pretty: As the name specifies, pretty is the prettier way to see the content. In this option, code will colorfully show with different keywords and have indentations in the code, which is useful for reading. Each color has different meanings. This makes the code nicer.

Raw: This is almost similar to pretty but shows the code without colors and in single lines. It is just a raw version of the code without any colorful keywords.

Preview: This will show the preview of the page that has been sent. It has the same page been run inside a browser. You just need to click on the preview, and you will get the exact page as you would have seen inside a browser.

Preview tab renders the response in a sandboxed iframe, and because of iframe sandbox restrictions, JavaScript and images are disabled in the iframe.

Format Type

Each request has a defined response to it as defined by the Content-Type header. That response can be in any format. Such as in the below example we have HTML code file:

You will see that we have multiple format types:

• JSON
• XML
• HTML
• Text
• Auto

Sometimes, the server sends the response in multiple formats. The type of format of response will be visible to its corresponding format type.

Copy Response

From the right-hand side of the response box, you can see two rectangles; that option is used for copying the complete response to the clipboard, which is very useful to send the response to anyone.

Cookies

Cookies are the small size of files which contain the information related to server files or website pages. Once you open the website for the first time, a cookie file will download on your system. This cookie has some information which will be used by the same site when you visit again. This allows the website to give a specific response and specific information according to your last visit.

Postman offers you to see the cookies that have been sent from the server as a response. We cannot make any changes to the cookies since we got from the server.

Try with the URL www.google.com and go to the Cookies section, you will get the cookie.

Headers

Headers are the extra information that is transferred to the server or the client. In the postman, headers will show like key-value pairs under the headers tab.

Once you select Headers option, you will get the following info:

---

API…Application Programming Interface… If you’re a developer then this word is nothing new for you…

Being a developer, you know the importance of API in any kind of application. In simple terms, API is a defined set of rules with some defined methods of communication. With the help of API, software components can interact with each other. You might have implemented some kind of APIs (such as payment gateway APIs) in your application. 

Implementing a quality API is really important to ensure fast development without compromising on the code quality. The best and popular tool for API testing among developers is Postman. 

In API testing we test the collection of APIs, and we check that whether your application fulfills the expectations of functionality, reliability, performance, and security. Also, we check that whether it returns the correct response or not. 

In API testing we check that whether the output is well-structured and useful for some other application or not. Depending on the input parameter we check the response, and we determine the time API is taking to extract the data and authorize the data to it. 

How Postman Works?

Postman sends the request to the webserver and then the server sends the response back to it. A user has to set all the headers and cookies API expects to check the response.  

You can install the postman from the link Postman. This tool provides a collection of API calls, and you need to follow these API calls for testing APIs of the application. You will find a dropdown list with multiple methods. 

You can select one of the methods from the given dropdown list. You will also have to include more information depending on the API call. This information are set as Authorization, Header, or body information. You just need to select one of the methods and send the request and get the response back.

Environment Variables in Postman

Some requests in POSTMAN require some specific information. You can make changes to these variables all at once instead of changing the variables in the endpoint manually. 

In the top right corner, you will get the option to set the environment variable. You can follow the steps given below to set the environment variable. 

1. In the top right corner click on Manage Environment from Settings.
2. Click on ADD button.
3. Mention the Name of the environment.
4. Mention key and value. This will be used as a variable in the collection later.

Add Collection

Collections are a bundle of requests. To create a collection, you can add an API call in the collection. You can reuse it in your application. A lot of organizations offer collections. You can import this in your postman and test it. If you have created a collection, you can export it or if you want the collection of others, you can import it. 

Your API call mainly uses two things…

1. HTTP Request

You make HTTP calls sending the HTTP Request. In HTTP request method includes Request Method, Request URL, Request Headers, Request Body, Pre-request Script, and Tests.

Let’s talk about these Request methods one by one… 

Request Methods: You will find several types of Request methods in POSTMAN. Depending on your requirements or test you can choose one of them. Mainly you will be using four request methods in your application. These methods are given below…

• GET Request: To retrieve or fetch data
• POST Request: To create and update data
• PUT Request; To update data
• DELETE Request: For deleting data

Request URL: You will find a long-width bar in Postman where you will have to enter the URL to make the HTTP request. 

Request Headers: In the request header, you enter the key value of the application. The two main key values are given below.

• Content-Type: The format of data is specified by Content-Type. Mainly developers use JSON format in the content type.
• Authorization: This information is included to identify the requester.

Request Body: In Postman, you will get the tab of Body where you can mention some specific information that needs to be sent with the request. You will get the option to send the data either in raw, binary, or any other form. Most of the time you will select raw form. You will also get the option of Pre-request scripts. This gets executed before a request is sent. In Postman, you are also allowed to write and run the test for each request. You can use JavaScript language for this.

2. HTTP Response

Once you send the request to Postman, you get the response back from the API that contains Body, Cookies, Headers, Tests, Status Code, and API Response time. Body and Header get organized in different tabs. Status code gets displayed in another tab with the time taken to complete the API call. Some important status codes are given below to verify the response.

• 200– For successful request.
• 201– For successful request and data was created
• 204– For Empty Response
• 400– For Bad Request. 
• 401– For Unauthorized access. Authentication failed or the user does not have permission for the requested operation. 
• 403– For Forbidden, Access Denied
• 404– For data not found.
• 405– For method not allowed or requested method is not supported.
• 500– Internal server error.
• 503– For Service unavailable

From the above explanation, you might have understood many things about Postman. How it works, how it is used for testing, request, response, and all the status code as well. Postman is the most popular tool among developers for API testing. There are many other tools as well, you can check out them as well, but the most popular one is POSTMAN and the reason behind its popularity is a lot of features included in it. 

Last Updated :
02 Oct, 2022

Like Article

Save Article

Уровень сложности
Средний

Время на прочтение
14 мин

Количество просмотров 20K

В мире современной разработки программного обеспечения, взаимодействие между различными приложениями через интерфейсы приложений (API) стало неотъемлемой частью разработки. Однако, прежде чем мы можем строить сложные взаимодействия, необходимо убедиться, что наш API работает корректно и предоставляет ожидаемые результаты.

И вот на сцену выходит Postman — мощный и интуитивно понятный инструмент, предназначенный специально для тестирования и разработки API. В этой статье рассказывается о самых базовых вещах, с которых следует начать свое знакомство с Postman.

Отправка HTTP-запросов, создание тестов, организация запросов в коллекции, работа с переменными — все это лишь часть функциональности Postman, которая облегчает процесс тестирования и повышает его эффективность. Если вы только начинаете свой путь в изучении этого инструмента, не волнуйтесь! Этот гайд поможет вам разобраться с базовыми принципами работы с Postman и покажет, как сделать ваш процесс тестирования API гораздо более эффективным и приятным.

Готовы начать? Давайте вместе погрузимся в увлекательный мир тестирования API с Postman!

Основные возможности и полезные функции Postman для QA-инженера:

1. Отправка HTTP-запросов: Postman позволяет легко создавать и отправлять различные типы HTTP-запросов, такие как GET, POST, PUT, DELETE и другие. Тестировщик может настраивать параметры запросов, передавать заголовки, параметры и тело запроса.

2. Тестирование API: Postman позволяет создавать тесты для проверки ответов от сервера. Тестировщик может определить ожидаемые значения и условия, чтобы автоматически проверить, что API возвращает правильные результаты.

3. Коллекции и среды: Postman позволяет организовывать запросы и тесты в коллекции, что упрощает управление большим числом запросов. Коллекции также можно использовать для автоматизации тестов или их запуска в определенной последовательности. Среды позволяют переключаться между различными конфигурациями окружения (например, тестовое, разработка, продакшн).

4. Работа с переменными: Postman поддерживает использование переменных, что облегчает тестировщикам управление и переиспользование данных в запросах, тестах и окружениях.

Возможностей у инструмента еще очень много, но в целом, Postman — это удобная программа для тестирования и работы с интерфейсами приложений (API). Тестировщик может создавать запросы к серверу и проверять полученные ответы. Postman также помогает организовать и автоматизировать тесты.

В этой статье мы:

• поговорим про HTTP методы и Статус-коды запросов

• познакомимся с интерфейсом программы

• научимся писать свои запросы и работать на реальных данных

• разберем запуск и автозапуск коллекций

• узнаем, что такое переменные и научимся ими пользоваться

• напишем первые автотесты

• разберемся, как использовать переменные с помощью CSV и JSON файлов

HTTP методы в REST:

Каждый метод имеет разную семантику. В реальной практике, конечно, возможно использовать любой метод для любого действия (например, использовать метод POST для всех запросов). Однако, в дальнейшем мы будем рассматривать их с точки зрения их первоначальной задумки.

Как выглядит HTTP запрос/ответ:

Какие бывают методы:

• Safe methods — никак не изменяем данные на сервере (своеобразный «read only»). Из-за этого называются безопасными. [Get; Head; Options; Trace]

• Idempotent methods — последовательные одни и те же запросы (после первого) на один и тот же ресурс. Никак не изменяют состояние сервера. Все Safe-методы идемпотентны. [Get; Head; Put; Delete; Trace; Options]

• Cacheable methods — поддаются кешированию. Большая часть идемпотентных методов кешируется хорошо, неидемпотентные — кешируются тяжело. [Get; Head; Options; Post; Patch]

HTTP методы:

• GET — в методе GET нет body и Payload (хотя, при сильном желании данные можно запихнуть в хедеры, путь и т.д.). Метод отвечает за получение данных.

• HEAD — проверяет состояние ресурса и ничего не возвращает. Кидаем HEAD, и если приходит код 200, можно спокойно отправить GET, и он вернет данные.
  Зачем? — HEAD легче и быстрее + HEAD не требует авторизации (потому что не возвращает никаких данных, а просто проверяет, что на сервер можно обращаться).

• OPTIONS — отвечает за получение данных о том, каким образом можно коммуницировать с сервером. В ответе сервера получаем методы => сервер принимает только «эти» методы и никакие другие.

• DELETE — удаляет данные/какую-либо сущность с сервера. В адресе он знает, кого именно удаляет (например, по id).

• PUT — обычно создает сущность либо изменяет ее: 1-й вызов — создание, 2-й и последующие вызовы с тем же запросом не будут изменять состояние сервера. Работает со всеми данными сущности. В своем адресе знает, кого создает/удаляет (например, указан id).

• PATCH — частичное обновление какой-то сущности. Не обязательно должны содержаться какие-то данные (например, «принять заказ», «отменить заказ»). Если содержит данные — пример: поменять значение поля «name» — изменит одно конкретное поле у сущности, но не затронет остальные.

• POST — используется только для создания чего-то нового. Если сущности ранее не было, он создаст (например, создать заказ).

• CONNECT — нужен, чтобы открыть каналы связи (например, SSL). Под капотом сейчас любой браузер делает это самостоятельно.

• TRACE — цепочка запросов. С помощью TRACE восстанавливается цепочка в обратном порядке и приходит в виде ответа. По данным из ответа можно понять, что происходило «до» этого.

Статус коды:

• 1XX — Informational (информационные) — указывают на то, что сервер получил и понял запрос, и клиенту стоит подождать немного дольше, чтобы сервер обработал информацию.

• 2XX — Success (Успешные) — успешные запросы означают, что запрос на доступ к ресурсу/файлу был выполнен успешно.

• 3XX — Redirection (Перенаправление/Редирект) — указывают на перенаправление. Означают, что клиент будет перенаправлен на URL, отличный от исходного.

• 4XX — Client Error (Ошибка клиента) — возникает ошибка на стороне клиента. Это может быть связано с неверным форматом данных, несанкционированным доступом, ошибкой в запросе и т.д.

• 5XX — Server Error (Ошибка сервера) — возникает ошибка на стороне сервера. Клиент сделал правильный запрос, но сервер не может сгенерировать запрошенный ресурс.

Подробнее про то, какие статус коды существуют и их значения можно прочитать в блоке «Дополнительно» в конце статьи

Начало работы

Postman приложение для пк можно скачать на официальном сайте. Также вы можете воспользоваться web версией.

Шаг 1: Для начала создадим свое «пространство».

Шаг 2: Знакомство с интерфейсом программы.

В левой боковой панели мы теперь можем организовывать свое пространство. 


(1) — коллекции — отправная точка для нового API. Можно рассматривать коллекцию, как файл проекта. Коллекция объединяет в себе все связанные запросы. Обычно API описывается в одной коллекции, но если вы желаете, то нет никаких ограничений сделать по-другому. Коллекция может иметь свои скрипты и переменные, которые мы рассмотрим позже.


Как выглядит конструктор:

(1) — вкладки с запросами

(2) — метод 

(3) — URL

(4) — отправка запроса
(5) — параметры запроса

(6) — параметры ответа

Шаг 3: определимся с API.

Вы можете использовать свой API, API своей компании или API с открытой документацией(!). Да, самое главное, чтобы у вас была под рукой документация, ведь без нее ничего не получится. Если на вашем продукте ее нет, то попросите backend разработчиков помочь вам и написать ее (они не обрадуются, но, будьте убедительны!).

Вот несколько примеров public API, которые можно использовать для практики:

• reqres (далее в гайде будем использовать этот ресурс)

• httpbin.org

• Petstore

• Cat facts

• Bored API

• agify.io

• nationalize.io

• Random dog images

Шаг 4: Создадим первую коллекцию

Сделать это можно либо нажав на «+» в левой боковой панели навигации, либо при нажатии на кнопку «new» напротив названия воркспейса (по крайней мере, сейчас так. В будущем внешний вид интерфейса может быть изменен, но, думаю, все еще будет интуитивно понятен).

При переходе в нашу созданную коллекцию можно увидеть вкладки:

Authorization — если мы хотим применить авторизацию для всей коллекции. К примеру, у нас есть какой-то логин/пароль для входа в систему и, чтоб не каждый раз применять их по новой, можно добавить данные сюда. Тогда авторизация будет применяться для всех реквестов по умолчанию.

Pre-request script — можно добавить пре-реквест скрипты, которые отработают до момента отправки нашего запроса не сервер. (Код на JS).

Tests — автотесты, которые будут отрабатываться для всех реквестов (к примеру, проверка, что статус код 200).

Variables — переменные, которые будут доступны внутри коллекции.

Шаг 5: Создадим первый запрос!

Для этого используем public API из шага 3, а конкретнее reqres.in. Выберем метод GET, на место ссылки вставляем https://reqres.in/api/users и, судя по документации, можем указать желаемую страницу просмотра

Запуск всей коллекции Postman

Если мы хотим запустить не один запрос, а пройтись сразу по нескольким, либо же запустить даже всю коллекцию — переходим в опции коллекции/папки и выбираем «Run».

Далее, выбираем, какие запросы мы хотим прогнать и можем поменять порядок их запуска.

В этом же открывшемся окне выбираем настройки нашего запуска. Можно настроить:

• автоматизацию запуска. В нашем случае, выберем «Run manually» (Запуск произойдет тогда, когда мы сами нажмем кнопку старта). Помимо этого, можно настроить автозапуск выбранных запросов раз в какое-то время, или же настроить вызов прямо из терминала.

• кол-во раз прогона запросов настраивается в поле Iterations.

• задержка между запросами и другие прикольные штуки.

После запуска мы видим окно со статистикой, статус наших тестов, если были и, можем запустить весь тот же набор повторно. Полученные результаты можно экспортировать (например для отчета).

Переменные и окружения Postman

Переменные можно добавлять как локально для какой-то коллекции (другие коллекции ее видеть не будут), так и глобально для всего окружения.

Для добавления переменных к коллекции необходимо перейти в ее настройки (достаточно просто нажать на коллекцию) во вкладку «Variables».

Там мы придумываем какое-то наименование нашей переменной и в «Current value» добавляем значение (для примера, родительский адрес, чтоб не перепечатывать его постоянно).

Переменные коллекции: Для чего используется «Initial value» и «Current value»: если вы работаете командой, то внеся изменения в «Initial value» — их увидят все и, при шаринге коллекции все будут видеть именно это значение. Если же вы хотите что-то проверить, но менять значение для всех пользователей, имеющих доступ нельзя — вы можете локально изменить «Current value» (эту информацию будете видеть только вы). Так же, в «Initial value» не рекомендуется добавлять какие-то чувствительные данные (например, пароли), тк эта информация, в отличии от «Current value» хранится на серверах постмона + ее видят все участники команды. 

Чтобы использовать нашу переменную, начните вводить фигурную скобку «{», система сама предложит варианты, в которых будут отображены и наши переменные. Все переменные заключаются в двойные фигурные скобки.

Хочется отметить, что переменные можно использовать не только в ссылках. Например, для многих запросов может требоваться авторизация по токену, который мы добавим в переменную. После смены токена достаточно будет изменить значение переменной, а не ходить по всем ручкам и проверять «ничего ли не забыл».

Environment — это набор каких-то переменных глобальных или для определенного окружения (к примеру, стенд A, стена B, прод). Чтобы посмотреть все окружения, которые сейчас есть — необходимо нажать на кнопку списка с глазом. Там же мы можем создать новое окружение. 

• Если мы выберем «Globals», то данные переменные могут применяться вообще ко всему. Они не привязаны к конкретному окружению и доступны всем. Как пример, можем занести туда информацию о логине (email + pass), если мы его будем часто использовать.

• Мы можем создать свое окружение, к примеру, «stage», в которое занесем данные об email. При выборе этого окружения, на места всех переменных email поставится значение из окружения «stage». При этом, на проде могут быть совсем другие данные => при создании еще одного окружения «production» и занесении туда такой же переменной email с другим значением — мы можем в одно действие менять значения переменных всех запросов на нужное.

Еще одно место, где можно использовать окружения/переменные — при запуске папки/коллекции (можно выбрать окружение, для которого будет выполнен прогон запросов).

Предустановленные тесты от Postman

Тесты можно прописывать во вкладке «Tests» для запроса. Здесь мы можем создавать свои скрипты, делать проверки, смотреть какие-то значение в респонсе (если мы знаем, что они там будут прописаны) и многое другое.

Предустановленные тесты находятся в блоке справа, который называется «Snippets». Мы их можем использовать и настраивать под себя. Один из распространенных тестов — проверка на статус код. Выбираем подходящий шаблон из списка и подставляем его.

Информация о прохождении наших тестов появляется во вкладке «Test Results». Успешные запросы — зелененькие. Если тест не прошел — ожидаемо, красненькие.

Теперь добавим тест на проверку того, что в ответе нам пришло какое-то значение. Из шаблонов выбираем «Response body: JSON value check». Вместо value пишем значение, которое хотим проверить.

Так же, теперь при запуске коллекции мы будем видеть все прошедшие и упавшие тесты:

Переменные в CSV и JSON файлах

CSV: Для начала создадим csv файл, в котором будет содержаться информация о нашем email и password. Вот несколько способов:

Способ 1: на windows можно создать обычный файл с расширением [.txt], которое мы изменим в последствии в проводнике. Либо, если у вас Mac — открываем TextEditor, вводим наши данные, сохраняем и при переименовании файла дописываем [.csv]. В всплывающем окне выбираем «использовать .csv».

Проверить, насколько корректно сохранился файл можно в любом редакторе кода* (открыть с помощью -> ваш редактор) и, если что, там же и подредактировать. [* если же у вас не стоит редактор кода — советую об этом позаботиться, тк ваша жизнь в IT еще ни раз вас подтолкнет им воспользоваться].

Способ 2: сконвертировать csv онлайн (не рекомендуется. В вашем файле могут появиться посторонние символы, которые будут мешать его правильному прочтению).

Способ 3: самый простой и надежный способ — создать файл сразу из редактора кода (далее рассмотрим «Visual Studio Code»). Открываем и выбираем «New File». Сразу вводим «Data.csv» и сохраняем. Далее там же редактируем сам файл и сохраняем изменения (На мой взгляд это куда проще, чем мучиться с созданием через обычный текстовый файл и переживать, а все ли хорошо сохранилось).

Теперь, как же правильно завести данные:

• в первой строке через запятую и без пробелов вводим название наших переменных;

• далее, в каждой следующей строке через запятую вводим комбинации-пары значений.

Далее переходим в Postman, создадим переменные (в нашем случае — email и password):

Давайте попробуем запустить нашу коллекцию! Перед стартом нажимаем на добавление файла и обязательно проверяем, что «Data File Type» выставился корректно. Если нет, можете поменять значение вручную. Так же здесь мы можем нажать на preview и посмотреть, правильно ли Postman прочитал наш файл.

Запускаем коллекцию и видим, что все 5 запросов успешно улетели. При нажатии на сам запрос можем посмотреть данные, которые мы как раз отправляли и убедиться, что ушло именно то, что хотели. (На статус код 400 в данном случае не обращайте внимания. Это из-за того, что мы используем OpenApi у которого есть свои внутренние ограничения).

JSON: по аналогии с созданием CSV файла — создадим JSON (способы описаны выше).

Как должен выглядеть JSON файл:

1. Данные записываются в виде пар «ключ:значение»

2. Пары данных разделены запятыми

3. Объекты прописываются внутри фигурных скобок {}

4. Массив (в том числе и из объектов) заключается внутри квадратных скобок []

Исходя из этого, заполняем наши тестовые данные.

Запускаем нашу коллекцию, выбрав только что созданный файл.

Запросы успешно отправляются!)

Заключение

Postman представляет собой важный и мощный инструмент, который может существенно упростить процесс тестирования и разработки API. В этой статье мы рассмотрели самые базовые аспекты работы с инструментом и познакомились с его функциональностью.

Теперь, имея базовое представление о том, как использовать различные методы HTTP, создавать запросы, организовывать тесты в коллекции и работать с переменными, вы можете эффективно исследовать и тестировать разнообразные API.

Помните, что Postman предоставляет множество возможностей для улучшения вашего рабочего процесса, включая автоматизацию тестов, создание документации и мониторинг производительности API. Это значит, что вы можете не только тестировать, но и оптимизировать работу вашего API, обеспечивая его стабильность и надежность.

Развивайтесь в использовании Postman, экспериментируйте с различными сценариями и подходами, и вы обязательно обретете уверенность в работе с API. Начните с малого, оттачивайте свои навыки и постепенно переходите к более сложным задачам.

Надеюсь, что данная статья помогла вам понять, с чего начать свое знакомство с Postman, и вдохновила на дальнейшее исследование этого полезного инструмента. Удачи в тестировании и разработке вашего API с помощью Postman!

Дополнительно:

Как и было обещано, список статус-кодов (самые популярные выделены жирным).

1XX:

• 100 — Continue — Продолжить — этот промежуточный ответ указывает, что запрос успешно принят и клиент может продолжать присылать запросы либо проигнорировать этот ответ, если запрос был завершён.

• 101 — Switching Protocol — указывает, что сервер переключился на протокол, который был указан в заголовке.

• 102 — Processing — сервер получил запрос и обрабатывает его, но обработка ещё не завершена.

• 103 — Early Hints — Ранние подсказки/ранняя метаинформация — разрешение пользовательскому агенту начать предварительную загрузку ресурсов, пока сервер все еще готовит ответ.

2XX:

• 200 — OK — запрос успешно обработан.

• 201 — Created — сервер подтвердил создание ресурса.

• 202 — Accepted — Принято — запрос клиента был получен, но сервер все еще обрабатывает его.

• 203 — Non-Authoritative Information — Не авторитетная информация — аналогично 200, но в этом случае предоставленная информация была не от исходного сервера, а из стороннего источника.

• 204 — No Content — Нет содержимого — сервер обработал запрос, но не предоставил никакого содержимого.

• 205 — Reset Content — Сбросить содержимое — клиент должен обновить документ, который прислал запрос.

• 206 — Partial Content — Частичное содержимое — клиент присылает заголовок диапазона, чтобы выполнить загрузку отдельно, в несколько потоков.

3XX:

• 300 — Multiple Choice — этот код ответа присылается, когда запрос имеет более чем один из возможных ответов. И User-agent или пользователь должен выбрать один из ответов.

• 301 — Moved Permanently — Перемещён на постоянной основе — искомый ресурс был перемещен по другому адресу. Все пользователи и ресурсы будут перенаправлены на него.

• 302 — Found — ресурс временно перемещен на другой URL.

• 303 — See Other — сообщает клиенту, что сервер перенаправляет его не на запрашиваемый ресурс, а на другой.

• 304 — Not Modified — используется для кеширования. Означает, что запрошенный ресурс не был изменен с последнего посещения.

• 305 — Use Proxy — клиент может получить доступ только через прокси, указанном в ответе.

• 307 — Temporary Redirect — Временное перенаправление — искомый ресурс был временно перенесен на другой URL. Различия с 302 — нельзя изменять используемый метод HTTP.

• 308 — Permanent Redirect — искомый ресурс был перемещен по другому адресу. Все пользователи и ресурсы будут перенаправлены на него.Различия с 301 — нельзя изменять используемый метод HTTP.

4XX:

• 400 — Bad Request — Плохой запрос — сервер не понимает запрос из-за неверного синтаксиса.

• 401 — Unauthorized — Неавторизованно — для получения запрашиваемого ответа нужна аутентификация. Статус похож на статус 403, но,в этом случае, аутентификация возможна.

• 402 — Payment Required — Необходима оплата.

• 403 — Forbidden — Запрещено — у клиента нет прав доступа к содержимому, поэтому сервер отказывается дать надлежащий ответ.

• 404 — Not Found — Не найден — сервер не может найти запрашиваемый ресурс. 

• 405 — Method Not Allowed — Метод не разрешён — сервер получил и распознал запрос, но отклонил конкретный метод запроса.

• 406 — Not Acceptable — веб сайт/приложение не поддерживает запрос клиента с определенным протоколом.

• 407 — Proxy Authentication Required — Требуется подтверждение протокола — аналог 401. Различие с 401 лишь в том, что аутентификации должна быть проведена через proxy.

• 408 — Request Timeout — Время ожидания запроса истекло — срок запроса, отправленного клиентом серверу — истек.

• 409 — Conflict — Этот ответ отсылается, когда запрос конфликтует с внутренним текущим состоянием сервера.

• 410 — Gone — запрашиваемый контент навсегда удалён с сервера.

• 412 — Precondition Failed — в заголовках запроса указаны условия, которые сервер не может выполнить.

• 413 — Request Entity Too Large — Размер запроса превышает лимит, объявленный сервером.

• 414 — Request-URL Too Long — URL запрашиваемый клиентом слишком длинный для того, чтобы сервер смог его обработать

• 417 — Expectation Failed — ожидание, полученное из заголовка запроса Expect, не может быть выполнено сервером.

• 418 — I’m a teapot — я чайник.

5XX:

• 500 — Internal Server Error — Внутренняя ошибка сервера — сервер столкнулся с ситуацией, которую он не знает как обработать.

• 501 — Not Implemented — Не реализовано — метод запроса не поддерживается сервером и не может быть обработан.

• 502 — Bad Gateway — Плохой шлюз — сервер, во время работы в качестве шлюза для получения ответа, нужного для обработки запроса, получил недействительный (недопустимый) ответ.

• 503 — Service Unavailable — Сервис недоступен — сервер недоступен и не может обработать запрос клиента.

• 504 — Gateway Timeout — сервер действует как шлюз и не может вовремя получить ответ.

• 505 — HTTP Version Not Supported — HTTP-версия, используемая в запросе, не поддерживается сервером.

• 511 — Network Authentication Required — Требуется сетевая аутентификация — клиент должен пройти аутентификацию в сети, чтобы получить доступ к ресурсу.