Testy API: kurs Postman w 6 lekcjach, od pierwszego żądania do CI

Testy API sprawdzają, czy aplikacje poprawnie rozmawiają ze sobą przez interfejs programistyczny: czy na dane żądanie wraca właściwy kod, właściwe dane i właściwy błąd, zanim ktokolwiek zobaczy ekran. Ten tekst to darmowy kurs testów API w Postmanie w sześciu lekcjach. Na końcu będziecie mieć kolekcję z 12 asercjami, którą uruchomiliśmy 10.10.2026 w Postman CLI i w Newmanie z wynikiem 12 na 12.

Jeśli dopiero instalujecie narzędzie i chcecie wiedzieć, czym jest i do czego służy, zacznijcie od przewodnika Postman: co to jest i jak zacząć testować API. Tutaj zakładamy, że Postman jest już na Waszym komputerze, i idziemy krok dalej: od pojedynczego żądania do zestawu testów, który sam uruchamia się przy każdej zmianie w kodzie.

Lekcja 1: co właściwie testujecie, gdy testujecie API?

Testujecie umowę między dwoma programami. API (Application Programming Interface) określa, jakie żądania można wysłać, pod jaki adres, w jakim formacie i co wróci w odpowiedzi. Klasyczne porównanie to kelner w restauracji: Wy zamawiacie (żądanie, ang. request), kelner zanosi zamówienie do kuchni, kuchnia przygotowuje danie, a kelner przynosi je do stolika (odpowiedź, ang. response). Nie wchodzicie do kuchni, a mimo to dostajecie to, co zamówiliście, o ile oboje trzymacie się karty dań.

W praktyce wygląda to mniej poetycko. Tomasz Stelmach, budując platformę do sprzedaży kursu online, nie pisał własnego systemu płatności: pobrał dokumentację API operatora płatności Tpay i według niej połączył platformę z bramką. Dokumentacja API jest właśnie taką kartą dań, a test API sprawdza, czy kuchnia naprawdę podaje to, co jest w karcie.

Skala zjawiska jest ogromna. Według raportu Postman State of the API 2025, przygotowanego na podstawie ankiety wśród ponad 5 700 programistów, architektów i menedżerów, 82% organizacji stosuje w jakimś stopniu podejście API-first, a 25% działa w pełni w tym modelu. Ten sam raport podaje, że 65% organizacji zarabia na swoich programach API. Gdy API jest produktem, jego testy przestają być dodatkiem do testów interfejsu.

Test API nie patrzy na przyciski i kolory. Patrzy na warstwę usług, w której siedzi logika biznesowa: czy rabat liczy się poprawnie, czy użytkownik bez uprawnień dostaje odmowę, czy błędne dane wracają z czytelnym komunikatem. Dlatego testy API można zacząć, zanim powstanie interfejs, i dlatego są szybsze oraz stabilniejsze niż testy przez przeglądarkę. Szerzej o miejscu testów API wśród poziomów testów piszemy w artykule testy integracyjne: co to jest, rodzaje i przykłady.

Lekcja 2: REST czy SOAP, co zmienia się w testach?

Zmienia się format i sztywność umowy, a nie sens testów. REST to styl architektoniczny opisany przez Roya Fieldinga w rozprawie doktorskiej z 2000 roku, a nie protokół z jednym standardem. SOAP to protokół wymiany komunikatów XML, którego wersja 1.2 jest rekomendacją W3C (drugie wydanie z 2007 roku). Specyfikacja SOAP 1.2 mówi wprost, że komunikat może być przesyłany różnymi protokołami bazowymi; w praktyce dominuje HTTP, ale SOAP nie jest do niego przywiązany.

Jedna poprawka, którą często widzimy w materiałach szkoleniowych: nie piszcie „szyfrowanie SSL”. Protokół SSL 3.0 został wycofany dokumentem IETF RFC 7568 w 2015 roku, a dzisiejsze HTTPS działa na TLS, w najnowszej wersji 1.3 opisanej w RFC 8446 z 2018 roku. Nazwa „certyfikat SSL” przetrwała w marketingu dostawców, ale w raporcie z testów bezpieczeństwa API piszcie o TLS i jego wersji. Uproszczeniem jest też zdanie, że SOAP to „najstarszy protokół API”: wcześniej były choćby XML-RPC i CORBA, SOAP jest po prostu najstarszym z tych, które spotkacie dziś w polskich bankach i systemach administracji.

Lekcja 3: które metody HTTP i kody odpowiedzi musicie znać?

Na start wystarczy pięć metod i dziesięć kodów. Specyfikacja HTTP Semantics, czyli IETF RFC 9110 z 2022 roku, opisuje też dwie cechy metod, które bezpośrednio przekładają się na przypadki testowe: bezpieczeństwo (metoda nie zmienia stanu serwera) i idempotentność (powtórzenie tego samego żądania daje ten sam efekt). Według RFC 9110 idempotentne są PUT, DELETE i metody bezpieczne, a POST nie.

Kody odpowiedzi, które pojawiają się w niemal każdym zestawie testów: 200 OK, 201 Created (utworzono zasób), 204 No Content, 400 Bad Request, 401 Unauthorized (brak ważnego uwierzytelnienia), 403 Forbidden (serwer rozumie żądanie, ale odmawia), 404 Not Found, 409 Conflict, 422 Unprocessable Content i 500 Internal Server Error. Różnica między 401 a 403 to klasyka rozmów rekrutacyjnych i klasyka błędów w API. Pełną ściągę z metodami opisujemy w artykule metody HTTP: GET, POST, PUT, PATCH i DELETE w testach API.

Lekcja 4: jak zamienić żądanie w test z pm.test?

Żądanie bez asercji to tylko podgląd odpowiedzi. Test powstaje wtedy, gdy w zakładce Scripts, w sekcji Post-response, dopiszecie funkcję pm.test z oczekiwanym wynikiem. Ćwiczymy na publicznym API Restful Booker, które Mark Winteringham przygotował do nauki testowania API: ma logowanie z tokenem, tworzenie, zmianę i usuwanie rezerwacji hotelowych, a co 10 minut wraca do stanu początkowego. Pierwszy test sprawdza utworzenie rezerwacji:

// Zakładka Scripts > Post-response w żądaniu POST /booking
pm.test('status 200', () => pm.response.to.have.status(200));
pm.test('odpowiedz ponizej 2 s', () => pm.expect(pm.response.responseTime).to.be.below(2000));

const body = pm.response.json();
pm.test('dane zgodne z wyslanymi', () => {
  pm.expect(body.booking.firstname).to.eql('Anna');
  pm.expect(body.booking.totalprice).to.eql(450);
  pm.expect(body.booking.bookingdates.checkin).to.eql('2026-11-02');
});

// identyfikator do kolejnych żądań w tej samej kolekcji
pm.collectionVariables.set('bookingId', body.bookingid);

Zwróćcie uwagę na trzy rodzaje asercji: status, czas odpowiedzi i dane. Sprawdzanie samego statusu 200 to najczęstszy błąd początkujących, bo API potrafi zwrócić 200 z pustą albo błędną treścią. Druga technika to walidacja schematu: zamiast porównywać każde pole, sprawdzacie, czy odpowiedź spełnia kontrakt, czyli ma wymagane pola właściwych typów.

// GET /booking/{{bookingId}}: kontrakt odpowiedzi zamiast pojedynczych pól
const schema = {
  type: 'object',
  required: ['firstname', 'lastname', 'totalprice', 'depositpaid', 'bookingdates'],
  properties: {
    totalprice: { type: 'integer' },
    depositpaid: { type: 'boolean' },
    bookingdates: { type: 'object', required: ['checkin', 'checkout'] }
  }
};
pm.test('zgodny ze schematem', () => pm.response.to.have.jsonSchema(schema));

Schemat łapie błędy, których pojedyncze asercje nie widzą: liczbę zwróconą jako tekst, brakujące pole albo null tam, gdzie front oczekuje obiektu. W naszych projektach automatyzacji testów API właśnie walidacja kontraktu najczęściej wychwytuje zmiany po stronie backendu, które „nic nie zmieniały”.

Lekcja 5: jak połączyć żądania w scenariusz z tokenem?

Przez zmienne kolekcji. Pierwsze żądanie loguje się i zapisuje token, drugie tworzy rezerwację i zapisuje jej identyfikator, kolejne używają obu wartości przez {{token}} i {{bookingId}}. Dzięki temu cała kolekcja jest scenariuszem od utworzenia do usunięcia danych i nie zostawia śmieci na środowisku testowym. Do scenariusza dokładamy test negatywny: zmiana rezerwacji bez tokenu musi skończyć się kodem 403.

Poniżej pełna kolekcja w formacie Postman Collection 2.1. Zapiszcie ją jako plik kurs-api.postman_collection.json i zaimportujcie przez Import w Postmanie albo uruchomcie od razu z wiersza poleceń.

{
  "info": {
    "name": "Kurs testow API - Restful Booker",
    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
  },
  "variable": [
    { "key": "baseUrl", "value": "https://restful-booker.herokuapp.com" }
  ],
  "item": [
    {
      "name": "01 Logowanie zwraca token",
      "request": {
        "method": "POST",
        "header": [{ "key": "Content-Type", "value": "application/json" }],
        "url": "{{baseUrl}}/auth",
        "body": { "mode": "raw", "raw": "{\"username\": \"admin\", \"password\": \"password123\"}" }
      },
      "event": [{ "listen": "test", "script": { "exec": [
        "pm.test('status 200', () => pm.response.to.have.status(200));",
        "const body = pm.response.json();",
        "pm.test('jest token', () => pm.expect(body.token).to.be.a('string').and.not.empty);",
        "pm.collectionVariables.set('token', body.token);"
      ] } }]
    },
    {
      "name": "02 Utworzenie rezerwacji",
      "request": {
        "method": "POST",
        "header": [
          { "key": "Content-Type", "value": "application/json" },
          { "key": "Accept", "value": "application/json" }
        ],
        "url": "{{baseUrl}}/booking",
        "body": { "mode": "raw", "raw": "{\"firstname\": \"Anna\", \"lastname\": \"Testowa\", \"totalprice\": 450, \"depositpaid\": true, \"bookingdates\": {\"checkin\": \"2026-11-02\", \"checkout\": \"2026-11-05\"}, \"additionalneeds\": \"Breakfast\"}" }
      },
      "event": [{ "listen": "test", "script": { "exec": [
        "pm.test('status 200', () => pm.response.to.have.status(200));",
        "pm.test('odpowiedz ponizej 2 s', () => pm.expect(pm.response.responseTime).to.be.below(2000));",
        "const body = pm.response.json();",
        "pm.test('dane zgodne z wyslanymi', () => {",
        "  pm.expect(body.booking.firstname).to.eql('Anna');",
        "  pm.expect(body.booking.totalprice).to.eql(450);",
        "  pm.expect(body.booking.bookingdates.checkin).to.eql('2026-11-02');",
        "});",
        "pm.collectionVariables.set('bookingId', body.bookingid);"
      ] } }]
    },
    {
      "name": "03 Odczyt rezerwacji i schemat",
      "request": {
        "method": "GET",
        "header": [{ "key": "Accept", "value": "application/json" }],
        "url": "{{baseUrl}}/booking/{{bookingId}}"
      },
      "event": [{ "listen": "test", "script": { "exec": [
        "pm.test('status 200', () => pm.response.to.have.status(200));",
        "const schema = {",
        "  type: 'object',",
        "  required: ['firstname', 'lastname', 'totalprice', 'depositpaid', 'bookingdates'],",
        "  properties: {",
        "    totalprice: { type: 'integer' },",
        "    depositpaid: { type: 'boolean' },",
        "    bookingdates: { type: 'object', required: ['checkin', 'checkout'] }",
        "  }",
        "};",
        "pm.test('zgodny ze schematem', () => pm.response.to.have.jsonSchema(schema));"
      ] } }]
    },
    {
      "name": "04 Zmiana bez tokenu jest zablokowana",
      "request": {
        "method": "PUT",
        "header": [{ "key": "Content-Type", "value": "application/json" }],
        "url": "{{baseUrl}}/booking/{{bookingId}}",
        "body": { "mode": "raw", "raw": "{\"firstname\": \"Ktos\", \"lastname\": \"Obcy\", \"totalprice\": 1, \"depositpaid\": false, \"bookingdates\": {\"checkin\": \"2026-11-02\", \"checkout\": \"2026-11-05\"}}" }
      },
      "event": [{ "listen": "test", "script": { "exec": [
        "pm.test('status 403 bez tokenu', () => pm.response.to.have.status(403));"
      ] } }]
    },
    {
      "name": "05 Zmiana z tokenem",
      "request": {
        "method": "PUT",
        "header": [
          { "key": "Content-Type", "value": "application/json" },
          { "key": "Accept", "value": "application/json" },
          { "key": "Cookie", "value": "token={{token}}" }
        ],
        "url": "{{baseUrl}}/booking/{{bookingId}}",
        "body": { "mode": "raw", "raw": "{\"firstname\": \"Anna\", \"lastname\": \"Testowa\", \"totalprice\": 520, \"depositpaid\": true, \"bookingdates\": {\"checkin\": \"2026-11-02\", \"checkout\": \"2026-11-06\"}, \"additionalneeds\": \"Breakfast\"}" }
      },
      "event": [{ "listen": "test", "script": { "exec": [
        "pm.test('status 200', () => pm.response.to.have.status(200));",
        "pm.test('nowa cena zapisana', () => pm.expect(pm.response.json().totalprice).to.eql(520));"
      ] } }]
    },
    {
      "name": "06 Usuniecie rezerwacji",
      "request": {
        "method": "DELETE",
        "header": [{ "key": "Cookie", "value": "token={{token}}" }],
        "url": "{{baseUrl}}/booking/{{bookingId}}"
      },
      "event": [{ "listen": "test", "script": { "exec": [
        "pm.test('status 201 (tak dziala to API)', () => pm.response.to.have.status(201));"
      ] } }]
    },
    {
      "name": "07 Usunieta rezerwacja zwraca 404",
      "request": {
        "method": "GET",
        "header": [{ "key": "Accept", "value": "application/json" }],
        "url": "{{baseUrl}}/booking/{{bookingId}}"
      },
      "event": [{ "listen": "test", "script": { "exec": [
        "pm.test('status 404', () => pm.response.to.have.status(404));"
      ] } }]
    }
  ]
}

Lekcja 6: jak uruchomić kolekcję w CI?

Z wiersza poleceń, tym samym plikiem, który klikaliście w Postmanie. Tu ważna aktualizacja, której nie znajdziecie w starszych poradnikach: według dokumentacji Postmana z 2026 roku Newman nie jest już rozwijany i nie obsługuje nowego formatu kolekcji v3 z Postmana v12, a zalecanym narzędziem jest Postman CLI. Kolekcje w formacie 2.1, takie jak ta z kursu, nadal uruchomicie oboma narzędziami.

# Postman CLI (zalecany przez Postmana, wersja 1.73.0 z 10.10.2026)
npm install -g postman-cli
postman collection run kurs-api.postman_collection.json

# Newman (starsze projekty, kolekcje w formacie 2.1)
npm install -g newman
newman run kurs-api.postman_collection.json --reporters cli,junit

Wynik przebiegu z 10.10.2026, skrócony do ostatnich kroków scenariusza:

→ 05 Zmiana z tokenem
  PUT https://restful-booker.herokuapp.com/booking/3626 [200 OK, 911B, 117ms]
  ✓  status 200
  ✓  nowa cena zapisana

→ 06 Usuniecie rezerwacji
  DELETE https://restful-booker.herokuapp.com/booking/3626 [201 Created, 743B, 118ms]
  ✓  status 201 (tak dziala to API)

→ 07 Usunieta rezerwacja zwraca 404
  GET https://restful-booker.herokuapp.com/booking/3626 [404 Not Found, 747B, 117ms]
  ✓  status 404

  requests: 7 executed, 0 failed    assertions: 12 executed, 0 failed

Ten sam przebieg wpinacie w potok, na przykład w GitHub Actions. Postman CLI uruchamia lokalny plik kolekcji bez logowania; konto Postmana jest potrzebne dopiero do wysyłania wyników do chmury Postmana.

# .github/workflows/testy-api.yml
name: Testy API
on: [push, pull_request]
jobs:
  api:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm install -g postman-cli
      - run: postman collection run tests/kurs-api.postman_collection.json

Od tego momentu każda zmiana w kodzie przechodzi przez Wasze 12 asercji, zanim trafi na środowisko testowe. U naszych klientów to właśnie testy API w potoku dają najszybszy zwrot z automatyzacji: działają w sekundach, nie zależą od układu strony i nie psują się przy zmianie koloru przycisku. Jeśli chcecie zbudować taki zestaw dla własnego systemu, zakres prac pokazuje strona usługi automatyzacja testów API.

Czy Postman jest darmowy?

Do nauki i pracy w pojedynkę tak, do pracy zespołowej nie. Cennik Postmana sprawdzony 10.10.2026 pokazuje cztery plany, a dokument FAQ cennika opisuje plany Free i Solo jako jednoosobowe; współpraca zespołowa zaczyna się od planu Team. To ważne przy wdrożeniu w firmie, bo wspólna kolekcja testów z wersjami i uprawnieniami wymaga płatnych licencji.

Kiedy Postman nie wystarcza?

Gdy testy API mają żyć w tym samym repozytorium co kod i być pisane przez programistów, gdy potrzebujecie testów obciążeniowych albo gdy pracujecie z ciężkim SOAP i WSDL. Postman jest świetny do nauki, eksploracji i regresji kontraktu, ale nie jest jedynym narzędziem w skrzynce.

Najczęstsze błędy, które łapią dobrze napisane testy API, to złe kody odpowiedzi (200 zamiast 401, jak w ćwiczeniu), brak walidacji pól wejściowych, niespójne typy danych między wersjami, wycieki danych w komunikatach błędów i luki w autoryzacji, gdy jeden użytkownik może odczytać zasób drugiego. Plan, jak przejść od takiej listy do automatyzacji w całej firmie, dobrze opisuje Strefa QA w tekście plan wdrożenia automatyzacji testów na 6 miesięcy.

Jak wygląda kurs testów API w Postmanie na szkoleniu?

Sześć lekcji z tego tekstu to szkielet. Na szkoleniu Wprowadzenie do testowania API: Postman przechodzicie ten sam materiał przez 2 dni warsztatów (2 x 7 godzin), z ponad 80% praktyki: kolekcje, zmienne i środowiska, autoryzacja, asercje i walidacja, scenariusze negatywne, testy sterowane danymi, serwery makiet oraz uruchamianie testów z wiersza poleceń i w CI. Cena na karcie szkolenia 10.10.2026: 1 707 zł netto, a szkolenie jest w Bazie Usług Rozwojowych, więc możecie starać się o dofinansowanie. Najbliższe terminy znajdziecie w kalendarzu szkoleń.

Z naszego doświadczenia po takim szkoleniu najwięcej zmienia nie znajomość przycisków, tylko nawyk pisania asercji do każdej odpowiedzi i testów negatywnych do każdego zabezpieczenia. Szkolenia prowadzą praktycy z minimum 5 latami w projektach, a zespół Quality Island napisał ponad 450 000 testów automatycznych. Jeśli wolicie najpierw porównać kursy online z wieloma narzędziami, przygotowaliśmy też zestawienie kursów testowania REST API na Udemy.

Powiązane na blogu Quality Island

• Postman: co to jest, do czego służy i jak zacząć testować API
• Testowanie API dla początkujących
• Postman: testy API i testy integracyjne w praktyce QA
• Metody HTTP: GET, POST, PUT, PATCH i DELETE w testach API
• Testy integracyjne: co to jest, rodzaje, przykłady

Pełna lista źródeł

• Postman, 2025 State of the API Report, 2025. Stąd 5 700 respondentów, 82% i 25% API-first oraz 65% organizacji z przychodem z API.
• Postman, Pricing, stan na 10.10.2026. Plany Free, Solo, Team i Enterprise.
• Postman, Newman CLI i Postman CLI overview, dokumentacja, stan na 10.10.2026.
• Postman, Test scripts, dokumentacja, stan na 10.10.2026.
• IETF, RFC 9110 HTTP Semantics, 2022. Metody bezpieczne i idempotentne, kody 201, 401, 403.
• IETF, RFC 8446 TLS 1.3, 2018, oraz RFC 7568 Deprecating SSL 3.0, 2015.
• W3C, SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), 2007.
• Roy T. Fielding, Architectural Styles and the Design of Network-based Software Architectures, rozdział 5 REST, 2000.
• Mark Winteringham, Restful Booker i dokumentacja API, publiczne API do ćwiczeń z celowo umieszczonymi błędami, odczyt 10.10.2026.
• Quality Island, karta szkolenia Wprowadzenie do testowania API: Postman i dane własne (450 000+ testów automatycznych), 2026.