Testowanie API od podstaw: żądania, kody odpowiedzi i Postman

Dlaczego tester powinien znać API

Większość aplikacji to dwie części: interfejs, który widzi użytkownik, i serwer, z którym interfejs rozmawia przez API. Gdy klikasz “Zapisz”, przeglądarka wysyła żądanie do API, a serwer odpowiada, czy się udało.

Testy przez API są szybsze i stabilniejsze niż przez interfejs, a do tego sprawdzają rzeczy, których w interfejsie nie widać: czy serwer odrzuca niepoprawne dane, gdy ktoś ominie walidację w przeglądarce, i czy nie odda cudzych danych. Dlatego testy API to osobna, ważna część testowania, a nie dodatek do testów interfejsu.

To piąta część serii “Testowanie od podstaw”.

Podejrzyj API w przeglądarce

Zanim otworzysz jakiekolwiek narzędzie, otwórz dowolną aplikację webową, naciśnij F12 i przejdź do zakładki Network (Sieć). Wykonaj jakąś akcję, np. wyszukaj produkt. Na liście pojawią się żądania. Kliknij jedno z typem fetch lub xhr i zobacz zakładki Headers, Payload i Response. To jest API, z którego korzysta aplikacja.

Ta zakładka przydaje się codziennie: gdy coś nie działa, od razu widać, czy problem jest w interfejsie, czy serwer zwrócił błąd.

Z czego składa się żądanie

Najczęstsze metody:

• GET pobiera dane;
• POST tworzy nowy zasób;
• PUT zastępuje cały zasób;
• PATCH zmienia część zasobu;
• DELETE usuwa zasób.

Z czego składa się odpowiedź

Odpowiedź ma kod statusu, nagłówki i treść, zwykle w formacie JSON. Kod statusu mówi, jak skończyło się żądanie:

Ważna zasada: błąd użytkownika to kod z grupy 4xx. Jeśli wysyłasz niepoprawne dane i dostajesz 500, to defekt, bo serwer nie obsłużył sytuacji, którą powinien przewidzieć. Pełniejszą tabelę kodów znajdziesz w pytaniach rekrutacyjnych.

Ćwiczenie w Postmanie

Do nauki dobrze nadaje się JSONPlaceholder, darmowe API z przykładowymi danymi. Przyjmuje wszystkie żądania, ale niczego nie zapisuje na stałe, więc nie da się w nim niczego zepsuć.

Krok 1. Pobierz dane. W Postmanie utwórz nowe żądanie GET na adres https://jsonplaceholder.typicode.com/posts/1 i kliknij Send. Dostaniesz kod 200 i taką strukturę:

{
  "userId": 1,
  "id": 1,
  "title": "...",
  "body": "..."
}

Krok 2. Utwórz zasób. Zmień metodę na POST, adres na https://jsonplaceholder.typicode.com/posts, w zakładce Body wybierz raw i JSON:

{
  "title": "Mój pierwszy test",
  "body": "Treść wpisu",
  "userId": 1
}

Odpowiedź powinna mieć kod 201 i zawierać wysłane dane z nowym id.

Krok 3. Dodaj testy. W zakładce Scripts (w starszych wersjach Tests) dopisz sprawdzenia, które Postman wykona po każdej odpowiedzi:

pm.test("status 201", () => {
  pm.response.to.have.status(201);
});

pm.test("zwraca wysłany tytuł i nowe id", () => {
  const json = pm.response.json();
  pm.expect(json.title).to.eql("Mój pierwszy test");
  pm.expect(json.id).to.be.a("number");
});

pm.test("odpowiedź w mniej niż 1 s", () => {
  pm.expect(pm.response.responseTime).to.be.below(1000);
});

Krok 4. Uporządkuj. Zapisz żądania w kolekcji, a adres bazowy przenieś do zmiennej środowiskowej, np. {{baseUrl}}/posts. Kolekcję możesz potem uruchomić w całości i wyeksportować do portfolio.

Co sprawdzać w API

Kod 200 to dopiero początek. Przy każdym endpoincie przejdź przez listę:

• Ścieżka pozytywna: poprawne dane, poprawny wynik, poprawny kod.
• Walidacja: brak wymaganych pól, zły typ (tekst zamiast liczby), za długie wartości, puste wartości.
• Nieistniejące zasoby: identyfikator, którego nie ma, powinien dać 404, nie 500.
• Uwierzytelnienie: żądanie bez tokena i z wygasłym tokenem.
• Uprawnienia: czy po podmianie identyfikatora w adresie, np. /orders/1001 zamiast /orders/1000, nie dostaniesz cudzego zamówienia. To jeden z najpoważniejszych błędów, jakie znajduje się w API.
• Duplikaty: co się stanie, gdy to samo żądanie POST wyślesz dwa razy.
• Skutki uboczne: czy dane naprawdę zapisały się w bazie, czy wysłał się e-mail.
• Treść błędu: czy komunikat jest zrozumiały i nie pokazuje szczegółów technicznych serwera.

Co dalej

Gdy Postman przestanie mieć dla Ciebie tajemnice, kolejny krok to sprawdzanie kształtu odpowiedzi, czyli testy kontraktowe API, i automatyzacja testów API w kodzie. O pierwszych krokach w automatyzacji opowiada ostatnia część serii.

Seria “Testowanie od podstaw”

1. Czym zajmuje się tester i jak zacząć
2. Teoria testowania w pigułce
3. Jak napisać przypadek testowy
4. Jak zgłaszać defekty
5. Testowanie API od podstaw (ten wpis)
6. Pierwsze kroki w automatyzacji testów