Jak testować punkty końcowe API

Interfejs programowania aplikacji (API) umożliwia komunikację między dwoma systemami. Zasadniczo API oferuje kontrakt i język regulujące komunikację między dwoma systemami. 

Testowanie API obejmuje ocenę tych interfejsów w celu upewnienia się, że spełniają one standardy funkcjonalności, niezawodności, wydajności i bezpieczeństwa, zazwyczaj poprzez wysyłanie różnych żądań do API i analizowanie odpowiedzi. Testowanie API jest priorytetem dla niemal wszystkich deweloperów — według globalnego badania API firmy Rapid z 2022 roku ponad 90% deweloperów testuje swoje API lub planuje je testować. 

Punkty końcowe API to określone ścieżki lub adresy URL udostępniane przez API, umożliwiające dostęp do różnych funkcji aplikacji. Każdy punkt końcowy odpowiada konkretnej funkcji, takiej jak pobieranie danych, aktualizowanie rekordu lub wykonywanie obliczeń, i jest zaprojektowany do obsługi określonych typów żądań i odpowiedzi w ramach ogólnej struktury API.

Regularne testowanie punktów końcowych API przez cały proces tworzenia oprogramowania pomaga wcześnie wykrywać problemy, oszczędzając w dłuższej perspektywie czas i zasoby.

Jak można efektywnie przeprowadzać testowanie API w całym cyklu życia tworzenia API? Przyjrzyjmy się temu!

Czym są punkty końcowe API?

API to zestaw reguł i protokołów służących do tworzenia aplikacji oraz korzystania z nich, umożliwiający komunikację między różnymi systemami oprogramowania. Dokumentacja i specyfikacje każdego API określają sposób wymiany danych.

API mogą używać żądań HTTP do pobierania danych z aplikacji internetowej lub serwera, podobnie jak renderowana jest strona internetowa.  

usługi, adresy URL, podobnie jak te używane podczas odwiedzania strony internetowej. W ramach API punkt końcowy to konkretna lokalizacja, która odbiera żądania i odpowiada na nie. Dzięki przesyłaniu i odbieraniu danych oraz poleceń za pośrednictwem punktu końcowego ułatwia komunikację między różnymi aplikacjami i systemami.

Umożliwia deweloperom szybki dostęp do danych i funkcji innych systemów oraz korzystanie z nich, oszczędzając im konieczności tworzenia wszystkiego od podstaw w nowych aplikacjach.

Przykład punktu końcowego API

Sprawdźmy, jak wygląda punkt końcowy API. Jako przykład wykorzystam Cat API i jego dokumentację Postman:

W tym przypadku punktami końcowymi są „images”, „favorites”, „breeds” itd. Każdy z nich umożliwia wykonywanie różnych działań za pomocą różnych metod żądań HTTP. Na przykład najczęściej używane metody to te, które wykonują operacje CRUD: POST służy do tworzenia, GET do odczytu, PUT do aktualizowania, a DELETE do usuwania.

Dokumentacja API powinna zawierać szczegółowe informacje o dostępnych punktach końcowych, metodzie żądania dozwolonej dla danego punktu końcowego oraz modelach żądania i odpowiedzi. Dysponując tymi informacjami, powinniśmy móc rozpocząć testowanie punktów końcowych. Omówimy to w jednej z kolejnych sekcji.

Dlaczego testować punkty końcowe API?

Każde API jest tworzone w celu realizacji określonych funkcji, a działanie aplikacji zależy od transakcji API, które mają zwrócić odpowiedź. Podstawowa transakcja może wykonywać wiele wewnętrznych wywołań API; jeśli jedno z tych wywołań się nie powiedzie, cały system może ulec awarii i przestać działać. Ponadto z tego samego API może korzystać wiele aplikacji, więc gdy API działa nieprawidłowo, może to zaszkodzić dużej liczbie aplikacji. Testowanie punktów końcowych API pomaga zapobiegać problemom, zanim wykryje je klient.

Jak testować punkty końcowe API

Testowanie API można przeprowadzać ręcznie, a także automatycznie. Oba rodzaje testów można wykonywać za pomocą narzędzi do testowania API.

W przeciwieństwie do testów interfejsu użytkownika testy API nie zależą od przeglądarki. Można jednak użyć narzędzia do testowania API, które działa jako klient.

Na podstawie dokumentacji możemy wyodrębnić punkt końcowy, do którego należy wysłać żądanie HTTP, metodę HTTP, parametry zapytania, treść żądania (jeśli jest wymagana), możliwe kody stanu odpowiedzi HTTP oraz treść odpowiedzi HTTP. Korzystając z tych informacji, możemy określić przypadki testowe API, które należy wykonać.

W zależności od wymagań możemy zdecydować, które testy należy wykonać — od testów funkcjonalnych po niefunkcjonalne, takie jak testy wydajności, testy obciążeniowe i testy bezpieczeństwa.

Najbardziej podstawowy test API polega na wysłaniu żądania i sprawdzeniu odpowiedzi. W zależności od typu żądania i samego punktu końcowego możemy potrzebować dodatkowych informacji, aby wysłać żądanie. Oto lista elementów, które musimy wysłać w żądaniu:

• Punkt końcowy/URL: jest to adres, na który wysyłane jest żądanie
• Treść żądania: w przypadku metod żądań takich jak POST i PUT wymagana jest treść zawierająca dane, które mają zostać wysłane do serwera
• Parametry zapytania: dodatkowe parametry wyszukiwania mogą służyć do ograniczenia wyników zwracanych w odpowiedzi 
• Nagłówki: są to metadane, które można wysłać wraz z żądaniem. W przytoczonym wcześniej przykładzie z kotem klucz API może być użyty jako nagłówek, co pozwala pobrać więcej informacji niż w przypadku braku klucza:

Po pomyślnym wysłaniu żądania test powinien sprawdzić odpowiedź. W odpowiedzi należy zwrócić uwagę na:

• Kod statusu HTTP: każda odpowiedź ma kod statusu. Można je podzielić na 5 głównych klas: kody rozpoczynające się od 1 (100–199) oznaczają odpowiedź informacyjną, kody rozpoczynające się od 2 (200–299) oznaczają pomyślną odpowiedź, kody od 300 do 399 oznaczają przekierowania, kody rozpoczynające się od 4 (400–499) oznaczają błędy klienta, a kody z grupy 500 oznaczają błędy serwera. 
• Treść odpowiedzi HTTP: informacje, które wracają z serwera. Dokumentacja powinna określać, jakie informacje powinna zawierać odpowiedź, na przykład:

• Nagłówki odpowiedzi: metadane zwracane przez serwery
• Czas odpowiedzi: jeśli interesuje nas również wydajność API.

Jako szybki przykład wykorzystam narzędzie Postman, aby pokazać, jak wygląda żądanie GET z użyciem Cat API. Wyślę żądanie GET do punktu końcowego obrazów. W tym celu wystarczy użyć adresu punktu końcowego, metody GET i wysłać żądanie:

Po wysłaniu żądania możemy zobaczyć kod odpowiedzi HTTP, treść odpowiedzi oraz czas potrzebny na jej otrzymanie:

Treść odpowiedzi to dane zwracane przez API na podstawie przekazanych danych wejściowych, natomiast kod statusu odpowiedzi wskazuje bieżący status żądania.

Odpowiedzi API mogą różnić się typami i rozmiarami danych. Odpowiedzi mogą mieć postać zwykłego tekstu, dokumentu XML, struktury danych JSON lub innych formatów. Mogą to być zarówno stustronicowe pliki JSON/XML, jak i prosty ciąg kilku słów, a nawet pusty wynik. Dlatego kluczowe jest wybranie odpowiedniej techniki weryfikacji dla konkretnego API.

Tworzenie przypadków testowych dla API

Funkcjonalne przypadki testowe można wyodrębnić za pomocą technik testowania czarnoskrzynkowego. Dokumentacja określa, jakie typy danych akceptuje każdy parametr, dlatego na ich podstawie można utworzyć partycje i wartości graniczne.

Następnie możemy tworzyć bardziej złożone scenariusze, łącząc wiele żądań w jeden test. Na przykład test, który tworzy zasób, aktualizuje go, odczytuje, a następnie usuwa, wyśle 4 różne żądania.

Zarówno testy pozytywne, jak i negatywne są niezbędne podczas testowania API, aby zweryfikować, czy API działa zgodnie z wymaganiami. Ponieważ testowanie API jest podzbiorem testowania czarnoskrzynkowego, dane wejściowe i wyjściowe są siłą napędową obu rodzajów testów. Oto kilka pomysłów na tworzenie scenariuszy testowych:

Scenariusze pozytywne:

• Sprawdź, czy API akceptuje dane wejściowe i generuje oczekiwany wynik zgodnie z wymaganiem.
• Sprawdź, czy kod statusu odpowiedzi — niezależnie od tego, czy zwraca kod błędu, czy kod 2xx — jest zwracany w sposób wskazany w wymaganiu.
• Określ minimalną i maksymalną liczbę pól, które należy wprowadzić.

Scenariusze negatywne:

• Upewnij się, że w przypadkach, gdy oczekiwany wynik jest nieobecny, API zapewnia odpowiednią odpowiedź.
• Przeprowadź test walidacji danych wejściowych.
• Przeanalizuj działanie API na różnych poziomach autoryzacji.

Niefunkcjonalne testy API 

Oprócz testów funkcjonalnych możemy przeprowadzać różne testy niefunkcjonalne API. Oto niektóre z najważniejszych:

Testy wydajnościowe

Testy wydajnościowe polegają na pomiarze wydajności oprogramowania przy różnych obciążeniach, scenariuszach i warunkach. Mogą pomóc w wykrywaniu wąskich gardeł zasobów, zagwarantowaniu stabilności i skalowalności oraz zapewnieniu skalowalności. Podtypy testów wydajnościowych obejmują testy obciążeniowe, testy przeciążeniowe, testy długotrwałego obciążenia i testy skokowe. Najpopularniejszy rodzaj testów wydajnościowych, znany jako testy obciążeniowe, odwzorowuje średni lub wysoki ruch użytkowników w oprogramowaniu. Może pomóc w ocenie przepustowości, czasu odpowiedzi i wykorzystania zasobów oprogramowania. Apache JMeter, narzędzie Java o otwartym kodzie źródłowym, które może generować i wysyłać różne żądania do interfejsu API oraz mierzyć wyniki, jest jednym z najlepszych narzędzi do testowania obciążenia interfejsu API.

Testy bezpieczeństwa

Proces potwierdzania, że oprogramowanie jest chronione przed złośliwymi atakami, nieautoryzowanym dostępem i naruszeniami danych, jest znany jako testowanie bezpieczeństwa. Może pomóc w zagwarantowaniu prywatności, dokładności i dostępności danych programu. Testy bezpieczeństwa można przeprowadzać na różnych poziomach, w tym na poziomie bazy danych, aplikacji i sieci. Przeglądy kodu, testy penetracyjne, skanowanie podatności i etyczne hakowanie to kilka popularnych metod testowania bezpieczeństwa. Postman to popularne, wieloplatformowe narzędzie, które może wysyłać i odbierać żądania do interfejsu API oraz testować funkcje bezpieczeństwa, takie jak uwierzytelnianie, autoryzacja, szyfrowanie i obsługa błędów. Jest to jedno z najlepszych narzędzi do testowania bezpieczeństwa interfejsu API.

Testy niezawodności

Testy niezawodności to proces określania, jak niezawodne i spójne jest oprogramowanie w czasie oraz w różnych sytuacjach. Mogą pomóc w zagwarantowaniu możliwości odzyskiwania po awarii, odporności na błędy i dostępności oprogramowania. Testy niezawodności można przeprowadzać poprzez celowe wprowadzanie do oprogramowania błędów, pomyłek lub awarii oraz obserwowanie jego reakcji i powrotu do działania. Średni czas między awariami (MTBF), średni czas do wystąpienia awarii (MTTF), średni czas naprawy (MTTR) i współczynnik awaryjności to kilka często stosowanych wskaźników w testach niezawodności. Chaos Monkey, narzędzie, które losowo kończy działanie instancji w środowisku chmurowym i sprawdza, jak oprogramowanie radzi sobie z zakłóceniami, jest jednym z najlepszych narzędzi do testowania niezawodności interfejsu API.

Końcowe przemyślenia

Testowanie API staje się coraz ważniejszą umiejętnością dla specjalistów ds. QA. Dokładne testowanie punktów końcowych API jest niezbędne, aby upewnić się, że działają zgodnie z przeznaczeniem i spełniają wymagane standardy. Testowanie punktów końcowych API pomaga identyfikować i usuwać potencjalne problemy lub błędy oraz weryfikuje ogólną funkcjonalność aplikacji.

Aby skutecznie testować punkty końcowe API, należy stosować najlepsze praktyki, takie jak projektowanie kompleksowych przypadków testowych, uwzględnianie różnych danych wejściowych i wyjściowych oraz korzystanie z narzędzi automatyzacji w celu zapewnienia wydajnego i niezawodnego testowania. Ponadto wykorzystanie środowisk testowych, które dokładnie symulują rzeczywiste scenariusze, może dodatkowo zwiększyć dokładność testowania punktów końcowych API.

Kompleksowe i skuteczne testowanie punktów końcowych API jest niezbędne do zapewnienia niezawodności, wydajności i funkcjonalności nowoczesnych aplikacji. Dzięki zrozumieniu, czym są punkty końcowe API i jak je testować, programiści mogą zapewnić pomyślną integrację swoich aplikacji z innymi systemami, jednocześnie zapewniając wyjątkowe doświadczenia użytkownika.

Subskrybuj newsletter QA Lead, aby otrzymywać aktualizacje dotyczące nowych treści na temat testowania.