Postman: testy API i testy integracyjne w praktyce QA

Czas czytania: około 13 minut

Aplikacja mobilna wyświetla listę zamówień w trzy sekundy, formularz rejestracji akceptuje polski PESEL, a płatność trafia do właściwego dostawcy zależnie od kraju klienta. Żadna z tych rzeczy nie dzieje się w interfejsie, który widzi użytkownik. Dzieje się w API, na które nakłada się logika biznesowa, integracje z innymi systemami i reguły walidacji. Testy API i testy integracyjne sprawdzają właśnie tę warstwę, a Postman jest narzędziem, w którym większość zespołów QA je pisze.

W tym tekście pokazujemy, czym są testy API i testy integracyjne, czym się różnią, jak zaprojektować je krok po kroku, co sprawdzać w odpowiedzi, jak pisać testy, które przetrwają rok, jak wpiąć je w CI/CD i regresję, kiedy Postman przestaje wystarczać oraz jakie błędy popełniają zespoły. Podstawy samego narzędzia (pierwsze żądanie, kolekcje, zmienne) opisujemy osobno w tekście o Postmanie, tu zakładamy, że już je znacie.

Czym są testy API i testy integracyjne w Postmanie?

Test API wysyła żądanie do jednego punktu końcowego i sprawdza jego odpowiedź w izolacji; test integracyjny łączy kilka żądań w scenariusz, który sprawdza, czy dane przepływają poprawnie między punktami końcowymi, usługami albo systemami.

Słownik ISTQB definiuje testowanie API jako testowanie wykonywane przez wysyłanie żądań do testowanego obiektu z użyciem jego interfejsu programistycznego. Test integracyjny w Postmanie to zwykle kilka żądań w jednej kolekcji, wykonywanych po kolei, gdzie wynik jednego (na przykład identyfikator utworzonego zamówienia) staje się danymi wejściowymi kolejnego. Pełną definicję testów integracyjnych i ich miejsce w piramidzie testów opisujemy w tekście Testy integracyjne: co to jest.

Czym różnią się testy API od testów integracyjnych?

Test API pyta „czy ten punkt końcowy działa poprawnie sam”, a test integracyjny pyta „czy te punkty końcowe działają poprawnie razem”; różnica jest podobna do różnicy między testem jednostkowym a testem integracyjnym w kodzie, tylko na poziomie usług zamiast funkcji.

Dlaczego testy API są dziś ważniejsze niż wcześniej: nowoczesne aplikacje składają się z wielu usług, integracji i warstw, a użytkownik widzi tylko formularz albo panel. Testy API pozwalają sprawdzić logikę systemu szybciej i stabilniej niż testy wyłącznie przez interfejs, bo są niżej w piramidzie testów: tańsze, szybsze i mniej podatne na zmiany wyglądu.

Podstawowe pojęcia: request, response, endpoint, environment, collection

Pięć pojęć wystarcza, żeby zacząć: request to żądanie wysyłane do serwera, response to jego odpowiedź, endpoint to konkretny adres, pod którym API udostępnia funkcję, environment to zestaw zmiennych dla danego środowiska, a collection to zestaw żądań zorganizowanych w scenariusz.

Pełny opis samych metod HTTP i tego, kiedy której użyć, rozkładamy w tekście Metody HTTP. Podstawy pracy z żądaniem, odpowiedzią i pierwszym testem w Postmanie opisujemy w tekście Postman: co to jest.

Jak zaprojektować testy API krok po kroku?

Testy API projektuje się w sześciu krokach: poznanie dokumentacji API, utworzenie workspace i kolekcji, konfiguracja środowisk, pierwsze żądanie, dodanie asercji oraz zaprojektowanie scenariuszy pozytywnych i negatywnych; pominięcie któregokolwiek z tych kroków zwykle kończy się kolekcją, która sprawdza mniej, niż wygląda.

Co sprawdzać w odpowiedzi API?

W odpowiedzi API sprawdza się status, strukturę odpowiedzi, dane biznesowe, walidację danych wejściowych, autoryzację i role oraz spójność między integrowanymi systemami; sprawdzenie tylko statusu 200 to najczęstszy powód, dla którego zestaw testów przechodzi, a błąd i tak trafia na produkcję.

• Status odpowiedzi. Nie tylko 200: sprawdźcie też, czy błędne żądanie zwraca właściwy kod błędu (400, 401, 404), nie 200 z komunikatem błędu w treści.
• Struktura odpowiedzi. Czy pole istnieje, ma właściwy typ (liczba, nie tekst) i nie jest puste tam, gdzie nie powinno.
• Dane biznesowe. Czy kwota po rabacie jest policzona poprawnie, czy status zamówienia zmienia się zgodnie z regułami procesu.
• Walidacja danych wejściowych. Czy API odrzuca niepoprawny e-mail, ujemną ilość, zbyt długi tekst, zamiast przyjąć je bez sprawdzenia.
• Autoryzacja i role. Czy użytkownik bez uprawnień dostaje 401 albo 403, nie dane, do których nie powinien mieć dostępu. To najczęstsza kategoria z OWASP Top 10 opisana w tekście o testach bezpieczeństwa.
• Integracje między systemami. Czy zamówienie utworzone w jednym serwisie faktycznie pojawia się w drugim, z tymi samymi danymi i bez utraty precyzji liczb czy znaków.

Jak pisać dobre testy API w Postmanie?

Dobry test API testuje zachowanie, nie tylko status, używa zmiennych zamiast wartości na sztywno, organizuje kolekcje według procesów biznesowych, ma osobne testy negatywne, waliduje treść komunikatów błędów i dba o dane testowe, które sam przygotowuje i sprząta.

Test API w Postmanie: scenariusz pozytywny i negatywny dla utworzenia zamówienia

// Scenariusz pozytywny
pm.test("Zamowienie utworzone, status 201", function () {
    pm.response.to.have.status(201);
});
pm.test("Odpowiedz zawiera identyfikator zamowienia", function () {
    const dane = pm.response.json();
    pm.expect(dane.id).to.be.a("number");
    pm.collectionVariables.set("idZamowienia", dane.id);
});

// Scenariusz negatywny: brak wymaganego pola "produktId"
pm.test("Brak produktId zwraca 400, nie 500", function () {
    pm.response.to.have.status(400);
});
pm.test("Komunikat bledu wskazuje brakujace pole", function () {
    const dane = pm.response.json();
    pm.expect(dane.blad).to.include("produktId");
});

Zmienna zbiorcza kolekcji (pm.collectionVariables) przekazuje identyfikator zamówienia do kolejnego żądania w scenariuszu integracyjnym, na przykład sprawdzenia statusu tego samego zamówienia. Jak w ogóle projektować dobre przypadki testowe, w tym dane brzegowe i klasy równoważności, rozkładamy w tekście o technikach projektowania testów, a zasady dobrej asercji w tekście Asercja: co to jest.

Automatyzacja: Postman w CI/CD, regresja i testy kontraktowe

Kolekcję testów API uruchamia się z wiersza poleceń przez Postman CLI albo Newman i wpina w pipeline CI/CD jako bramkę przed wdrożeniem; ten sam zestaw służy do regresji API po każdej zmianie, a przy integracjach z zewnętrznymi systemami dokłada się testy kontraktowe, które sprawdzają zgodność interfejsu bez uruchamiania prawdziwej usługi drugiej strony.

Budowę takich potoków, w tym bramki jakości przed wdrożeniem, prowadzimy w ramach budowy procesów CI/CD oraz automatyzacji testów API.

Testy w Postmanie sprawdzają API, ale nie powiedzą, czy użytkownik widzi na stronie tę samą cenę, którą zwraca backend. Test łączący odczyt frontu z odpowiedzią API w Pythonie opisujemy w artykule o web scrapingu w testach oprogramowania.

Kiedy Postman nie wystarcza?

Postman przestaje wystarczać przy bardzo dużej liczbie testów wymagających integracji z kodem produkcyjnym, przy złożonych scenariuszach z logiką warunkową trudną do wyrażenia w skryptach JavaScript, przy protokołach innych niż REST (SOAP, gRPC) oraz gdy zespół chce trzymać testy API w tym samym repozytorium i języku co aplikację.

• REST Assured. Biblioteka Javy do testów API, gdy zespół pisze w Javie i chce trzymać testy w repozytorium aplikacji, obok testów jednostkowych. Uczymy na szkoleniu REST Assured: testy integracyjne dla testerów.
• SoapUI. Dla API w SOAP, starszych systemów korporacyjnych i integracji, których Postman nie obsługuje natywnie. Szkolenie: Testy integracyjne SoapUI dla testerów.
• Testy jednostkowe zamiast API. Gdy logika, którą chcecie sprawdzić, nie wymaga sieci ani bazy danych, test jednostkowy w kodzie aplikacji jest szybszy i tańszy niż test API w Postmanie.
• Katalon albo kod niskopoziomowy. Przy bardzo dużych zestawach z potrzebą złożonej logiki warunkowej, wersjonowania i code review na poziomie kodu, nie kolekcji klikanej w interfejsie.

Jakie są najczęstsze błędy w testowaniu API?

Najczęstsze błędy to sprawdzanie tylko statusu 200, brak testów negatywnych, ręczne wpisywanie danych zamiast zmiennych, chaotyczne kolekcje bez struktury, brak przygotowania i sprzątania danych testowych, brak kontroli autoryzacji, brak wersjonowania kolekcji oraz automatyzacja bez strategii, czyli zestaw rosnący bez planu.

1. Tylko status 200. Odpowiedź może mieć poprawny status i błędne dane. Sprawdzajcie też strukturę i wartości.
2. Brak testów negatywnych. Ścieżka pozytywna to połowa pracy. Błędne dane, brak autoryzacji i przekroczone limity to druga połowa.
3. Dane na sztywno. Wpisany identyfikator zamówienia przestaje istnieć po tygodniu. Zmienne i skrypty przygotowujące dane rozwiązują problem.
4. Chaotyczne kolekcje. Żądania bez struktury, bez nazw mówiących, co sprawdzają. Organizacja według procesów biznesowych, nie przypadkowej kolejności zapisu.
5. Brak sprzątania danych. Test, który tworzy zamówienia i nigdy ich nie usuwa, zaśmieca środowisko testowe i utrudnia kolejne przebiegi.
6. Brak kontroli autoryzacji. Testy tylko na koncie administratora nie wykrywają, że zwykły użytkownik widzi cudze dane.
7. Brak wersjonowania. Kolekcja bez repozytorium to jeden plik na dysku jednej osoby, który znika razem z laptopem.
8. Automatyzacja bez strategii. Setki testów bez priorytetów i bez podziału na regresję krytyczną i pełną. Zestaw rośnie, czas wykonania też, wartość niekoniecznie.

Jak zaprojektować proces testów API w firmie?

Proces testów API w firmie buduje się w dziesięciu krokach: zakres API, ryzyka, scenariusze pozytywne i negatywne, dane testowe, kolekcje, asercje, cykliczne uruchamianie, analiza wyników, powiązanie z decyzją o wydaniu oraz utrzymanie zestawu w czasie.

Zaprojektowanie takiego procesu, wraz z audytem obecnego stanu testów API, prowadzimy w ramach strategii jakości oprogramowania. Kompetencje budujemy na szkoleniu Wprowadzenie do testowania API Postman, a ścieżkę rozwoju w stronę testowania API opisujemy w tekście Testowanie oprogramowania: ścieżki rozwoju. Wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Powiązane na blogu Quality Island

• Postman: co to jest, do czego służy i jak zacząć testować API
• Testy integracyjne: co to jest, rodzaje, przykłady i jak je wykonywać krok po kroku
• Metody HTTP
• Asercja: co to jest i jak używać asercji w testach
• Testy bezpieczeństwa i testy penetracyjne: co sprawdzają, rodzaje i jak je zlecić
• Piramida testów: co to jest, warstwy, proporcje i techniki projektowania testów

Pełna lista źródeł

• ISTQB Glossary, hasło API testing
• Postman, Introduction oraz Test scripts
• Dane własne Quality Island z projektu dla Argos, e-commerce, liczby potwierdzone przez klienta; ponad 450 000 napisanych testów automatycznych, ponad 152 zrealizowane projekty