Testing

Kilka słów o testowaniu API

Marzec 25, 2021 0
Podziel się:

Testowanie aplikacji kojarzy mi się z poznaniem jej, sprawdzeniem, czy wszystko działa zgodnie z projektem, a także z weryfikacją i przetestowaniem również tego, co jest niewidoczne dla użytkownika! Z testowaniem API właśnie 🙂

Zanim przejdziemy do rozwinięcia tego akronimu, na początek zastanówmy się nad samym testowaniem aplikacji. Dla przykładu – w jaki sposób przetestujesz stronę internetową z polem „imię”, które może składać się maksymalnie z 20 znaków?

Domyślam się, że na początek sprawdzisz, czy pole może być puste. Następnie zweryfikujesz przykładowe imiona, których zakres mieści się w wymaganiach. Kolejnym krokiem może być sprawdzenie wartości granicznych – wpisanie imienia o 20 i 21 znakach. Jeśli 21 znaków nie spowoduje błędu, to może rozbicie słowa na dwa dużo mniejsze i rozdzielone spacją, ukaże prawdziwe oblicze aplikacji? Nie, wszystko wciąż działa dobrze. Nie wykryto błędów. Zespół zatem poprawnie napisał tę funkcjonalność. Zatwierdzasz ją jako przetestowaną i działającą. Strona może iść na produkcję.

Po tygodniu, gdy popijasz kawę, dostajesz informację zwrotną od biznesu o tytule „NA PRODUKCJI WYKRYTO KRYTYCZNY BŁĄD” oraz treści: „w polu „imię” została zapisana wartość o długości 21 znaków”. Jak to możliwe? Przecież wszystko zostało sprawdzone i przetestowane! Developerzy napisali kod, a testerzy potwierdzili poprawne działanie funkcjonalności!

Czy domyślasz się, co poszło nie tak?

Dobrze podejrzewasz 🙂 – zawinił brak wiedzy i doświadczenia. Nikt nie zasugerował, że samo przetestowanie funkcjonalności na frontendzie (czyli za pomocą samej przeglądarki i interfejsu graficznego) to nie wszystko. Czasami konieczne jest również przetestowanie połączenia pomiędzy frontendem, a backendem. Jak jednak tego dokonać z poziomu zwykłego użytkownika? W tym celu możemy (i powinniśmy) wykorzystać znajomość API! Jeśli jest już wykonana walidacja na frontendzie, to wcale nie oznacza, że backend nie wymaga naszej uwagi.

API to angielski akronim od słów Application Programming Interface. Jest to zbiór metod służących do komunikacji pomiędzy dwoma systemami. Dzięki użyciu tego interfejsu, dostęp do zasobów jest łatwiejszy i bezpieczniejszy (pod warunkiem, że są dobrze zaprojektowane), a dodatkowo ułatwiona jest wymiana danych pomiędzy różnymi platformami. API pozwala użyć danych bez wglądu w szczegóły implementacji.

Ze względu na to, że głównie pracuję z aplikacjami webowymi, zacznę od opisania architektury klient-serwer (client-server). W tym podejściu klientem może być przeglądarka, telefon lub inna aplikacja. Operacje i zadania wykonane po stronie klienta muszą być odwzorowane po stronie serwera. Aby doszło do wymiany danych pomiędzy klientem, a serwerem powinny zostać wysłane wiadomości. Wg standardu W3C do komunikacji sieciowej może być użyty protokół HTTP (Hypertext Transfer Protocol), a konkretnie wiadomości HTTP (HTTP messages). Takimi wiadomościami będą żądania (requests) i odpowiedzi (responses).

Jak wygląda to w praktyce?

Wyobraź sobie formularz do rejestracji uczestnika na zawody motocyklowe. Po wypełnieniu formularza na stronie internetowej (po stronie klienta) klikasz „wyślij”. Kliknięcie przycisku powoduje wysłanie żądania do serwera. Serwer przetwarza żądanie i odsyła odpowiednią odpowiedź, którą następnie widzi klient. Tyle w teorii. Przejdźmy do strony technicznej.

API webowe jest podzielone na 3 typy:

  • prywatne,
  • partnerskie,
  • zewnętrzne.

Prywatne API jest zbudowane i wykorzystywane np. w przypadku aplikacji używanych przez pracowników jednej firmy (z ograniczonym dostępem z zewnątrz). Partnerskie API jest dostępne dla każdego, kto spełni odpowiednie warunki. Głównie używane jest do integracji pomiędzy firmami. Zewnętrzne API jest z kolei dostępne dla każdego.

Najpopularniejszymi typami API są:

  • REST
  • SOAP
  • RPC
  • oraz, od pewnego czasu, GraphQL.

Najczęściej używanym typem jest REST. I to jemu poświęcę kolejny akapit 🙂

REST API (Ang. Representational State Transfer) jest architekturą oraz zbiorem zasad. API RESTowe umożliwia wykorzystanie dowolnego formatu danych – np. JSON, XML. Korzystając z RESTowego API wykorzystujesz tzw. CRUD, czyli następujące operacje:

  • Utwórz (Create)
  • Odczytaj (Read)
  • Zmodyfikuj (Update)
  • Usuń (Delete).

W przypadku REST API wykorzystasz następujące metody:

  • Create – będzie to głównie metoda POST
  • Read – metoda GET
  • Update – metoda PUT/PATCH
  • Delete – metoda DELETE.

Oczywiście to tylko czubek góry lodowej. Samo REST API można wykorzystać do szeregu innych operacji jak np. restart serwera.

Czemu warto wykorzystać API w testowaniu?

Po pierwsze testy API to nie tylko testy funkcjonalne. API jest na tyle elastycznym rozwiązaniem, że możesz wykorzystać je jako podstawę do testów wydajności, bezpieczeństwa czy niezawodności. Początkowy przykład i problem z polem „imię” testy z wykorzystaniem API wykryłyby niemal natychmiast. Prawdopodobnie udałoby Ci się zapisać do bazy danych imię składające się z 23 znaków i takim testem sprawdzić poprawność pola, używając np. Swaggera lub konsoli deweloperskiej (popularne F12).

Zastanów się – jakie inne pola powinny także uwzględniać walidację zarówno na frontendzie jak i backendzie? Np. pola, których niedostateczne przetestowanie mogłoby wywołać o wiele poważniejsze konsekwencje!

Poza tym uwzględniając w testach API możesz zweryfikować konkretne żądania (bez potrzeby wywołania ich na frontendzie). Ba! Możesz wręcz pominąć frontend! Oprócz tego możesz wykorzystać swoje umiejętności przy nowoczesnych projektach pokroju technologii Internetu Rzeczy (która opiera się o API), dodatkowo mając świadomość, że podążasz za najnowszymi trendami. Przecież Shift Left opiera się o koncepcję „testowania bliżej kodu”.

Podsumowując, ten „API” nie jest taki najgorszy 🙂


Chcesz lepiej zrozumieć aplikacje i systemy, które testujesz? Dołącz do ModernTester, poznaj najpotrzebniejsze narzędzia, frameworki oraz języki programowania i ćwicz na specjalnie przygotowanych środowiskach testowych: Platforma e-learningowa ModernTester

Oceń ten post
Kategorie: Testing
Emilia Lendzion-Barszcz
Autor: Emilia Lendzion-Barszcz
Tester w SII Polska oraz szkoleniowiec. Na co dzień zajmuje się testowaniem backendu – szeroko rozumianą automatyzacją, wydajnością oraz testami jednostkowymi, zaś po godzinach chwyta adrenalinę za sprawą m.in. enduro. https://www.facebook.com/JavaGirlPL

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz