Postman: co to jest, do czego służy i jak zacząć testować API

Czas czytania: około 12 minut

Formularz na stronie wygląda na sprawny, dopóki ktoś nie sprawdzi, co się dzieje pod spodem: czy serwer zwraca właściwy status, czy odpowiedź ma poprawny format, czy błędne dane w ogóle zostają odrzucone. Postman jest narzędziem, które pozwala zadać te pytania bezpośrednio interfejsowi programistycznemu aplikacji, bez klikania przez ekrany. Ten tekst prowadzi od zera: czym jest Postman, jak wysłać pierwsze żądanie, jak zamienić je w test, jak zorganizować testy w kolekcję ze zmiennymi środowiskowymi i jak uruchamiać je poza samym narzędziem, w tym w pipeline.

Co to jest Postman?

Postman to aplikacja do wysyłania żądań HTTP i pracy z API: pozwala zbudować żądanie bez pisania kodu, wysłać je do serwera, obejrzeć odpowiedź, dopisać do niej sprawdzenie i zapisać całość jako powtarzalny test w kolekcji.

Według dokumentacji Postmana to platforma API do projektowania, testowania, dokumentowania i monitorowania interfejsów, z klientem desktopowym, wersją w przeglądarce i rozszerzeniem VS Code. Dla testera oznacza to jedno: zamiast prosić developera o „sprawdź w kodzie, co zwraca ten endpoint”, otwiera Postmana i sprawdza sam, w minutę.

Postman nie zastępuje testów przez interfejs użytkownika, tylko dokłada warstwę niżej: sprawdzenie, czy backend robi to, co powinien, zanim ktokolwiek zobaczy wynik na ekranie. To jest dokładnie ten poziom piramidy testów, na którym błąd kosztuje najmniej: znaleziony w Postmanie to pięć minut, ten sam błąd znaleziony na produkcji to zgłoszenie od klienta.

Do czego służy Postman?

Postmana używa się do eksploracji API (sprawdzenia, jakie dane zwraca dany punkt końcowy), do testowania (sprawdzenia, czy odpowiedź spełnia oczekiwania), do dokumentowania (kolekcja z opisami jako żywa dokumentacja dla zespołu) oraz do automatyzacji (uruchamianie zestawu testów w pipeline przy każdej zmianie kodu).

Jak wysłać pierwsze żądanie w Postmanie?

Pierwsze żądanie w Postmanie to cztery kroki: wybór metody HTTP (najczęściej GET), wpisanie adresu punktu końcowego, kliknięcie Send i odczytanie odpowiedzi w panelu poniżej; nie trzeba znać kodu ani konfigurować niczego, żeby zobaczyć pierwszy wynik.

Pierwsze żądanie: publiczne API testowe

Metoda:  GET
Adres:   https://jsonplaceholder.typicode.com/users/1
Wyślij:  przycisk Send

Odpowiedz (fragment):
{
  "id": 1,
  "name": "Leanne Graham",
  "email": "Sincere@april.biz",
  "address": { "city": "Gwenborough" }
}
Status: 200 OK      Czas: 120 ms      Rozmiar: 509 B

Pierwsze kroki w dokumentacji Postmana prowadzą przez dokładnie ten scenariusz na publicznym API testowym, bez potrzeby zakładania konta ani konfiguracji serwera. Jeśli dopiero zaczynacie z API w ogóle, zanim przejdziecie do Postmana, warto przeczytać Testowanie API dla początkujących.

Jak odczytać odpowiedź API?

Odpowiedź API składa się z czterech elementów, które Postman pokazuje osobno: kodu statusu (czy żądanie się udało), nagłówków (metadane odpowiedzi, na przykład format danych), ciała odpowiedzi (właściwe dane) oraz czasu odpowiedzi; każdy z nich niesie inną informację i każdy warto sprawdzać osobno.

Jak zmienić żądanie w test: pierwsza asercja

Żądanie staje się testem, gdy w zakładce Scripts dopiszecie skrypt sprawdzający wynik: najprostszy test porównuje kod statusu z oczekiwanym, kolejne sprawdzają kształt i wartości w ciele odpowiedzi; bez takiego skryptu Postman tylko pokazuje wynik, nie ocenia go.

Pierwszy test w zakładce Scripts (Postman, JavaScript)

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

pm.test("Odpowiedz zawiera imie uzytkownika", function () {
    const dane = pm.response.json();
    pm.expect(dane.name).to.eql("Leanne Graham");
});

pm.test("Czas odpowiedzi ponizej 500 ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

To dokładnie ta sama zasada co w każdym innym narzędziu testowym: porównanie wyniku rzeczywistego z oczekiwanym. Dokumentacja skryptów testowych Postmana pokazuje więcej gotowych fragmentów do wklejenia. Czym jest sama zasada asercji i jak pisać dobre sprawdzenia, rozkładamy w tekście Asercja: co to jest i jak używać asercji w testach.

Co to są kolekcje i po co ich używać?

Kolekcja to folder żądań, które razem opisują scenariusz: logowanie, utworzenie zamówienia, sprawdzenie jego statusu, usunięcie danych testowych; kolekcja uruchamia się jednym kliknięciem, da się ją przekazać innej osobie w zespole i jest jednostką pracy, nie pojedyncze żądania zapisane luzem.

Kolekcje porządkują żądania w foldery, pozwalają ustawić kolejność wykonania i dodać wspólne skrypty uruchamiane przed każdym żądaniem w kolekcji. Pojedyncze żądanie zapisane bez kolekcji jest prywatną notatką testera, nie testem, który zespół może powtórzyć.

Zmienne środowiskowe: żeby nie wpisywać adresu na sztywno

Zmienne środowiskowe przechowują adres serwera, token i identyfikatory poza treścią żądania, dzięki czemu ten sam zestaw testów uruchamiacie na środowisku testowym i produkcyjnym bez jednej poprawki, a przy zmianie tokenu podmieniacie go w jednym miejscu, nie w każdym żądaniu z osobna.

Zmienne środowiskowe: "Testowe" kontra "Przedprodukcyjne"

Środowisko: Testowe                    Środowisko: Przedprodukcyjne
{{baseUrl}}  = https://test.firma.pl   {{baseUrl}}  = https://staging.firma.pl
{{token}}    = testowy-token-abc       {{token}}    = staging-token-xyz

Żądanie (bez zmian między środowiskami):
GET {{baseUrl}}/api/zamowienia/123
Authorization: Bearer {{token}}

Zmienne to jeden z czterech nawyków, które odróżniają zestaw testów żyjący przez rok od takiego, który psuje się po pierwszej zmianie środowiska: adres serwera, token i identyfikatory w zmiennych, nie w treści żądania.

Jak uruchomić kolekcję testów jednym kliknięciem?

Kolekcję uruchamia się w Postmanie przez Collection Runner: jedno kliknięcie odpala wszystkie żądania po kolei, z podsumowaniem, ile testów przeszło, a ile nie, i z możliwością podania danych wejściowych z pliku CSV dla wielu wariantów tego samego scenariusza.

Collection Runner pokazuje wynik każdego testu w kolekcji z osobna, więc padnięcie jednego żądania nie ukrywa wyniku pozostałych. To narzędzie do szybkiej regresji API bez pisania kodu, ale ma granicę: uruchamia się ręcznie, z klikniętego przycisku, dopóki nie przeniesiecie tego do wiersza poleceń, o czym niżej.

Postman poza klikaniem: CLI i automatyzacja w pipeline

Kolekcję da się odpalić z wiersza poleceń przez Postman CLI albo starszy Newman, a stamtąd już tylko krok do uruchamiania jej automatycznie w pipeline CI/CD po każdej zmianie w kodzie; to granica, za którą testy przestają zależeć od tego, czy ktoś pamiętał je kliknąć.

Postman CLI uruchamia kolekcję poleceniem w terminalu i zwraca kod wyjścia, który pipeline rozumie jako sukces albo porażkę, dokładnie jak każdy inny krok budowania. Newman robi to samo w starszym, wciąż wspieranym wariancie. Więcej przykładów testów API i integracyjnych, w tym wpięcie w pipeline, pokazujemy w tekście Postman: testy integracyjne i testy API w praktyce.

Ile kosztuje Postman?

Postman ma darmowy plan wystarczający na naukę i pracę indywidualną (limit żądań i wywołań miesięcznie), a płatne plany dodają współpracę zespołową, więcej przestrzeni roboczych i uruchomień w chmurze; sam klient desktopowy do wysyłania żądań i pisania testów jest bezpłatny niezależnie od planu.

Aktualny cennik i limity planu darmowego sprawdźcie na stronie cennika Postmana, bo zmieniają się częściej niż raz w roku. Dla zespołu zaczynającego naukę plan darmowy wystarcza na wszystko z tego przewodnika.

Najczęstsze błędy początkujących w Postmanie

Najczęstsze błędy początkujących to adres serwera i token wpisane na sztywno w każdym żądaniu, pojedyncze żądania bez kolekcji, żądania bez ani jednej asercji, dane testowe przygotowywane ręcznie przed każdym uruchomieniem oraz kolekcja, która nigdy nie opuszcza klikniętego przycisku w aplikacji.

1. Wartości na sztywno. Adres serwera i token w treści żądania zamiast w zmiennych środowiskowych. Zmiana środowiska wymaga poprawienia każdego żądania z osobna.
2. Żądania bez kolekcji. Zapisane luzem, bez kolejności, bez możliwości przekazania zespołowi. Prywatna notatka, nie test.
3. Zero asercji. Żądanie wysłane i obejrzane ręcznie nie jest testem. Bez skryptu w zakładce Scripts nikt nie oceni wyniku automatycznie.
4. Dane przygotowywane ręcznie. Konto testowe zakładane przed każdym uruchomieniem zamiast skryptem w kolekcji, który sam przygotowuje i sprząta dane.
5. Tylko klikanie. Kolekcja, która nigdy nie trafia do wiersza poleceń ani do pipeline, zależy od tego, czy ktoś pamiętał ją uruchomić przed wydaniem.

Jak przełożyć te nawyki na pełny warsztat testowania API, w tym testy integracyjne i wpięcie w CI/CD, pokazujemy w tekście Postman: testy integracyjne i testy API w praktyce. Kompetencje budujemy na szkoleniu Wprowadzenie do testowania API Postman. Wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Najczęstsze pytania o Postmana

Co to jest Postman?

Postman to narzędzie do wysyłania żądań HTTP i pracy z API: pozwala zbudować żądanie bez pisania kodu, wysłać je do serwera, obejrzeć odpowiedź i dopisać do niej sprawdzenie, które zamienia żądanie w powtarzalny test.

Do czego służy Postman?

Do eksploracji nieznanego API, testowania (sprawdzania, czy odpowiedź spełnia oczekiwania), dokumentowania interfejsów jako żywej dokumentacji dla zespołu oraz automatyzacji, czyli uruchamiania zestawu testów w pipeline przy każdej zmianie kodu.

Jak wysłać pierwsze żądanie w Postmanie?

Wybierzcie metodę HTTP (najczęściej GET), wpiszcie adres punktu końcowego, kliknijcie Send i odczytajcie odpowiedź w panelu poniżej: status, nagłówki, ciało i czas odpowiedzi. Nie trzeba pisać kodu ani niczego konfigurować.

Jak zamienić żądanie w test?

W zakładce Scripts dopiszcie skrypt porównujący wynik rzeczywisty z oczekiwanym, na przykład pm.test sprawdzający kod statusu albo konkretną wartość w odpowiedzi. Bez takiego skryptu Postman pokazuje wynik, ale go nie ocenia.

Co to są kolekcje w Postmanie?

Foldery grupujące żądania w scenariusz, który uruchamia się jednym kliknięciem i da się przekazać zespołowi. Pojedyncze żądanie zapisane bez kolekcji jest prywatną notatką, nie testem zespołowym.

Po co są zmienne środowiskowe w Postmanie?

Przechowują adres serwera, token i identyfikatory poza treścią żądania, dzięki czemu ten sam zestaw testów uruchamiacie na różnych środowiskach bez zmian w żądaniach, a przy zmianie tokenu podmieniacie go w jednym miejscu.

Czy Postmana można uruchomić z wiersza poleceń?

Tak, przez Postman CLI albo starszy Newman. Kolekcja uruchomiona tak zwraca kod wyjścia, który pipeline CI/CD rozumie jako sukces albo porażkę, co pozwala uruchamiać testy automatycznie przy każdej zmianie kodu.

Czy Postman jest darmowy?

Klient do wysyłania żądań i pisania testów jest bezpłatny. Płatne plany dodają współpracę zespołową, więcej przestrzeni roboczych i uruchomień w chmurze. Aktualne limity sprawdźcie na stronie cennika Postmana.

Powiązane na blogu Quality Island

• Postman: testy integracyjne i testy API w praktyce QA
• Testowanie API dla początkujących
• Asercja: co to jest i jak używać asercji w testach
• Testy integracyjne: co to jest, rodzaje, przykłady i jak je wykonywać krok po kroku
• Piramida testów: co to jest, warstwy, proporcje i techniki projektowania testów
• Narzędzia do testowania oprogramowania: przegląd najlepszych rozwiązań

Pełna lista źródeł

• Postman, Introduction, Sending the first request, Collections, Variables, Test scripts, Collection Runner, Postman CLI, Newman
• Cennik Postmana
• Dane własne Quality Island z projektu dla Argos, e-commerce, liczby potwierdzone przez klienta; ponad 450 000 napisanych testów automatycznych