Zapraszamy na nasze szkolenie z testowania API – Postman – Przejdz do szkolenia

 

Aplikacje, systemy, elementy oprogramowania potrzebują się ze sobą komunikować. Dokładnie tak jak ludzie. Komunikujemy się, aby realizować pewne rzeczy lub wymieniać się informacjami. W tym celu wykorzystujemy różne sposoby komunikacji takiej jak: gesty, słowa, pismo, głos itp. Aplikacje również mają swoje sposoby komunikacji! Komunikacja między aplikacjami zwykle odbywa się z wykorzystaniem rozwiązania pośredniczącego, na przykład interfejsu programistycznego API. Mimo, że API nie jest widoczne, gdyż istnieje „pod maską” aplikacji, to musisz mi uwierzyć na słowo, że wykorzystujesz API na co dzień! Do czego?? Być może słuchasz muzyki np. na Tidalu, czy oglądasz filmy na Netflixie, logujesz się do aplikacji swojego banku, czy zamawiasz pizze na pyszne.pl? Jeśli tak to wszędzie tutaj, do uzyskania swojego celu – korzystasz z jakiejś komunikacji API!

 

Co to jest API?

 

API (Application Programming Interface) to sposób komunikacji między aplikacjami bądź elementami, komponentami oprogramowania. API określa zbiór zasad, reguł, funkcji, procedur w obrębie których aplikacje mogą się ze sobą komunikować. API dostarcza nam zdefiniowane „requesty” (żądania), które możemy wykonywać – określając dodatkowo konkretne sposoby ich tworzenia, jak i formaty danych, które możemy stosować.

 

API od strony technicznej możemy zdefiniować, jako kod programistyczny, który kontroluje punkty dostępowe aplikacji, komponentu lub serwera.
API działa jako pośrednik, pozwalając programistom na budowanie nowych interakcji pomiędzy różnymi aplikacjami.

 

Jak zastosowanie interfejsu API może wyglądać w praktyce? Na myśl, przychodzi mi sytuacja, którą przerabiałem jakiś czas temu. Stworzyłem kurs online o testowaniu oprogramowania, automatyzacji testów i chciałem mieć na stronie jakiś system płatności online, aby każdy chętny użytownik, mógł kilkoma kliknięciami dokonac płatności za kurs i otrzymać do niego dostęp. Co zatem zrobiłem? Oczywiście nie tworzyłem nowego systemu płatności! Po prostu, pobrałem dokumentację API do systemu płatności np. Tpay i zgodnie z zawartymi tam instrukcjami, opisami metod połaczyłem swoja platformę szkoleniową z systemem płatności. Czyli krótko mówiąć, opierając się na dokumentacji API, która tak naprawdę jest jasną instrukcją dla programistów, która pomaga w zaimplementowaniu potrzebnych funkcjonalności – połączyłem swoją platformę z systemem płatności.

 

Jak to działa technicznie?

 

Już powiedzieliśmy sobie, że możemy traktować API jako pośrednika między aplikacja a serwerem. Kiedy chcemy wykonać jakąś akcję w aplikacji, np. włączyć swój ulubiony film, wówczas klikając np. w kafelek z filmem – aplikacja użyje API do komunikacji z serwerem wydając mu konkretne polecenie – żądanie. Następnie serwer podejmie akcję i wyśle odpowiedz spowrotem do aplikacji. Tłumacząc jak działa komunikacja API – zawsze posługuję się przykładem, który kiedyś znalazłem w Internecie i podzielę się nim również z Wami. Będzie to abstrakcyjny przykład, który moim zdaniem oddaje wydawać by się mogło skomplikowana istotę API. Wyobraźmy sobie, że jesteśmy w restauracji, zajmujemy stolik. Podchodzi do nas kelner z menu. Zapoznajemy się z kartą dań i po chwili kelner odbiera od nas zamówienie. W tym przypadku, kelner jest naszym pośrednikiem między nami a kucharzem (który będzie przygotowywał nasze zamówienie). W końcu kucharz nie może bezpośrednio przyjąć naszego zamówienia, gdyż ma swoją pracę do wykonania. A więc zgłaszasz żądanie (request) do kelnera, który przesyła to żądanie do kucharza. Następnie kucharz przygotuje Twoje danie, a kelner przynosi je do Twojego stolika. Tak więc kelner jest personifikacją API, czyli jest elementem komunikacyjnym miedzy naszym stolikiem a kuchnią.

 

Typy API

 

Wyróżniamy dwa główne, najpopularniejsze typy API: Rest API i SOAP API

 

SOAP

 

SOAP – ( Simple Object Access Protocol ). Jest to najstarszy protokół API, który wciąż żyje i jest szeroko wykorzystywany. Myślę, że nie jest to protokół ulubiony wśród programistów, gdyż korzystanie z protokołu SOAP wymaga sporo pracy. Przede wszystkim trzeba utworzyć dokumenty XML, a formatowanie XML wymagane przez SOAP nie jest do końca intuicyjne. Ale SOAP ma również swoje mocne strony. Przede wszystkim opiera się na standardowych protokołach, zwłaszcza HTTP i SMTP. Oznacza to, że możesz używać SOAP praktycznie w każdym środowisku, ponieważ protokoły te są dostępne we wszystkich systemach operacyjnych.

 

REST

 

REST (Representational State Transfer). REST (tak jak SOAP) opiera się na standardowym protokole HTTP do wymiany informacji między różnymi aplikacjami lub usługami. Jednak REST jest bardziej elastyczny, ponieważ obsługuje różne formaty danych, zamiast tylko formatu XML. Szczególnie przyjemnym i szeroko wykorzystywanym formatem danych jest JSON, który jest znacznie bardziej czytelny i łatwiejszy w tworzeniu niż XML. Interfejsy REST mogą również oferować lepszą wydajność niż SOAP, ponieważ są w stanie buforować informacje.

 

 

 

REST API VS SOAP API

 

 

 

 

 

 

Jak i po co testować API?

 

Teraz kiedy już wiemy, czym jest API, możemy w końcu przejść do zagadnień związanych z testowaniem API.

 

TESTOWANIE API to rodzaj testowania oprogramowania, który testuje interfejsy programowania aplikacji. Celem testowania API jest sprawdzenie funkcjonalności, niezawodności, wydajności API. Główną cechą odróżniającą testowanie API od standardowego testowania manualnego jest to, że testując API – zamiast używać standardowych danych wejściowych (klawiatury, myszki) i wyjściowych, używasz specjalistycznego oprogramowania do wysyłania wywołań do API i odczytywania, interpretowania odpowiedzi systemu. Testy API nie koncentrują się na wyglądzie i GUI. Koncentrują się za to na warstwie logiki biznesowej(warstwa usług) architektury oprogramowania. W uproszczeniu można przyjąć, że standardowe aplikacje mają trzy główne warstwy:

 

• warstwę danych (warstwa bazodanowa)
• warstwę usług (warstwa API)
• warstwę prezentacji (GUI)

 

Logika biznesowa aplikacji — przewodnik po tym, jak użytkownicy mogą wchodzić w interakcje z usługami, funkcjami i danymi przechowywanymi w aplikacji — znajduje się w warstwie API.  Testowanie API koncentruje się na analizie logiki biznesowej oraz bezpieczeństwa aplikacji i odpowiedzi na dane. Standardowy pojedynczy test API to po prostu wysłanie żądania/zapytania (requestu) do jednego lub więcej punktów końcowych API (endpoint) i analizę oraz porównywanie odpowiedzi (response) z oczekiwanymi wynikami.

 

Pojawiły nam się tutaj 3 kluczowe terminy:

 

• Request (żądanie, zapytanie) – jest to komunikat który wysyłamy do serwera / usługi w celu realizacji jakiego zadania.
• Response (odpowiedz) – jest to komunikat odpowiedzi na wysłany request.
• Endpoint – Miejsce sieciowe, link pod którym znajduje się określona, pojedyncza usługa API. np http://odlaikadoautomatyka.pl/users

 

 

Metody HTTP

 

Mamy wiele metod HTTP, które wykorzystywane są przez REST API. Jednak najważniejsze i zdecydowanie najbardziej popularne, najczęściej wykorzystywane są tylko cztery z nich: GET, POST, PUT/PATCH, DELETE. Dobra znajomość tych czterech metod pozwoli już sprawnie przeprowadzać testy API.

 

 

 

• GET
• POST
• PUT
• DELETE
• CONNECT
• OPTIONS
• TRACE
• PATCH
• HEAD

 

GET –  przeznaczona do pobierania danych

POST – przeznaczona do tworzenia i przesłania nowych danych

PUT / PATCH– podobna do metody POST. Cechą odróżniającą PUT od POST jest to, że zapytanie PUT musi wskazywać na konkretny zasób. PUT jest używany głównie do aktualizowania istniejących zasobów. Metoda PUT jest również podobna do metody PATCH, z tym, że PUT nadpisuje cały zasób – dla częściowego nadpisania służy metoda PATCH.

DELETE – metoda przeznaczona do usuwania danych

 

Narzędzia do testowania API

 

Wspomniałem wyżej, że testy API wykonuje się z wykorzystaniem specjalistycznego oprogramowania. Oprogramowanie to pomaga nam tworzyć oraz wysyłać requesty do odpowiednich enpointów oraz umożliwiają przechwytywanie odpowiedzi i ich interpretację. Zatem zobaczmy jakie są aktualnie najpopularniejsze narzędzia, rozwiązania dostępne na rynku.

 

 

 

Rest Assured

 

Rest Assured umożliwia testowanie interfejsów API REST z wykorzystaniem języka programowania JAVA. Jest to obecnie najpopularniejsza w tym języku biblioteka do testowania API.  Biblioteka ta jest stosunkowo prosta w obsłudze, nawet dla osób, które nie mają dużego doświadczenia z programowaniem w języku JAVA.

 

Może być używana do testowania usług internetowych opartych na XML i JSON. Obsługuje żądania GET, POST, PUT, PATCH, DELETE, OPTIONS i HEAD i może być używana do walidacji i weryfikacji odpowiedzi na te żądania. Może być również zintegrowana z popularnymi frameworkami testowymi, takimi jak JUnit, TestNG itp.

 

Postman

 

Postman to bardzo popularne narzędzie do testowania API, które zyskało swoją popularność dzięki bardzo prostemu i intuicyjnemu interfejsowi. W odróżnieniu od Rest Assured nie musimy posiadać umiejętności programowania, aby skutecznie i efektywnie przeprowadzać testy API. Należy również zaznaczyć, że oprogramowanie jest w pełni darmowe. Mimo prostoty użytkowania, posiada naprawdę duże możliwości, między innymi możliwości automatyzacji testów!

 

Apache JMeter

 

 

 

 

JMeter to popularne narzędzie do testowania wydajności wydane na licencji open source (zupełnie darmowe), które jest przeznaczone do testowania obciążenia i wydajności. Może być używany do analizowania i mierzenia wydajności różnego typu oprogramowania, obejmującego usługi, w tym sieci i serwery.
Jmeter umożliwia tworzenie planu testów funkcjonalnych oprócz planu testów wydajnościowych . Główne cechy:
• Obsługuje wiele źródeł obciążenia, którymi można zarządzać za pomocą jednego kontrolera
• Nie wymaga zaawansowanej infrastruktury do prostych testów wydajnościowych
• Wymaga mniejszych nakładów pracy na tworzenie skryptów w porównaniu z innymi narzędziami do testowania wydajności API, ponieważ ma przyjazny dla użytkownika interfejs
JMeter obsługuje między innymi następujące protokoły – HTTPS, HTTP, XML, protokoły oparte na Javie, SOAP i FTP.

 

 

Fiddler

Fiddler to proste, kiedyś bardzo popularne narzędzie (dzisiaj wydaje się, że lata świetności ma już za sobą). Jest to narzędzie debugujące proxy, które pozwala na monitorowanie, przechwytywanie, debugowanie oraz modyfikowanie ruchu HTTP/HTTPS pomiędzy komputerem a aplikacjami.

 

Jak testować API?

Aby rozpocząć w ogóle proces testowania API musimy w pełni zrozumieć jak ma działać dane API. W tym celu mogą nam pomóc odpowiedzi na następujące pytania:

• Jakie mamy dostępne endpointy (lista endpointów)?
• Jakie kody odpowiedzi (kody HTTP) są oczekiwane dla poszczególnych żadań?
• Jakie kody odpowiedzi są oczekiwane w przypadku nieudanych żądań?
• Jakie komunikaty o błędach powinny pojawić się w treści nieudanego żądania?

 

Kiedy znamy odpowiedzi na powyższe pytania, możemy przejść do fazy wykonywania testów. Oczywiście dobrze jest, kiedy mamy przypadki testowe, które w jasny i jednoznaczny sposób mówią nam, jakie endpointy z jakimi danymi mają zwracać konkretne odpowiedzi. Dzięki temu każdy test będzie łatwy do oceny, czy otrzymane wyniki zgadzają się z wynikami oczekiwanymi. Oczywiście kody odpowiedzi (kody odpowiedzi HTTP) są tutaj bardzo istotne, ale powinniśmy zwracać uwagę jeszcze na inne elementy, takie jak: czas odpowiedzi, jakość danych, poprawność autoryzacji czy komunikaty błędów.

 

Oprócz testowania wykonywania wywołań API, czyli testów w pewnym sensie funkcjonalnych powinniśmy wykonywać również inne, niefunkcjonalne testy, takie jak:

 

• testy bezpieczeństwa

testom poddawane są np. metody szyfrowania, testy kontroli dostępu, kontrola autoryzacji , zarządzanie uprawnieniami

 

• testy wydajnościowe

testujemy tutaj głównie to, ile wywołań może obsłużyć interfejs API i jak zachowuje się przy różnym obciążeniu.

 

• testy niezawodności

weryfikujemy tutaj czy interfejs API jest w stanie generować spójne, jednoznacznie wyniki, weryfikujemy również stabilność połączenia miedzy aplikacjami

 

• Testy rozmyte

wymuszają wprowadzanie do systemu ogromnych ilości losowych danych – zwanych również szumem lub rozmyciem – próbując wywołać negatywne zachowanie, takie jak wymuszona awaria lub przepełnienie.

 

Przykład testów API

Prostym i obrazowym przykładem testów APU są systemy rezerwacji lotów, takie jak esky.pl. Użytkownicy oczekują, że wszystkie najtańsze opcje lotów w określonych terminach będą dostępne i wyświetlane na żądanie podczas korzystania z systemu rezerwacji lotów. Wymaga to od aplikacji komunikacji ze wszystkimi liniami lotniczymi w celu znalezienia najlepszych opcji lotu. Odbywa się to za pośrednictwem interfejsów API. W rezultacie należy przeprowadzić testy API, aby upewnić się, że system rezerwacji podróży skutecznie komunikuje się z innymi firmami i przedstawia prawidłowe wyniki użytkownikom w odpowiednim czasie.

 

Najczęstsze błędy wychwytywane przez testy API

• problemy z wydajnością ( zbyt długi czas dostępu do usługi)
• problemy z niezawodnością (niespójne, niejednoznaczne wyniki, problemy z połączeniem miedzy aplikacjami)
• problemy związane z wielowątkowością
• problemy związane z bezpieczeństwem (możliwość nieuprawnionego dostępu, problem z szyfrowaniem danych)
• odpowiedź zawiera niekompletne dane
• problemy z parsowaniem, formatowanie danych

 

 

Korzyści ze stosowania testów API?

• Testowanie interfejsu API umożliwia rozpoczęcie testowania na wczesnym etapie cyklu rozwoju, zanim interfejs użytkownika będzie gotowy, co niesie ze sobą dowie podstawowe korzyści. Po pierwsze możemy znaleźć błędy na bardzo wczesnym etapie fazy tworzenia oprogramowania. To powoduje, że koszt naprawy błedu na tak wczesnym etapie projektu jest niski. Oszczędzamy w tej sytuacji czas i pieniądze. Po drugie możemy zacząc fazę intensywnych testów już od samego poczatku fazy tworzenia oprogramowania co pomaga nam osiagać wysoką jakośc już od samego poczatku.
• Prostsza budowa automatyzacji testów. Na pewno automatyzacja testów API wymaga mnie kodu i mniej utrzymania niż automayzacja testów GUI. To sprawia, że koszty takiej automatyzacji są niższe.
• Testy API są niezależne od technologii i języka. Dane są wymieniane za pomocą JSON lub XML i zawierają żądania i odpowiedzi HTTP.
• Testy API są znacznie szybsze i bardziej wydajne niż testy GUI
• Testy API mogą stanowić uzupełnienie testów GUI

 

Oczywiście testwanie API ma też swoje słabsze strony i stwarza również wyzwania. Najczęstsze ograniczenia spotykane w testach API to wybór parametrów, kombinacje parametrów i sekwencjonowanie wywołań. Wybór parametrów wymaga sprawdzenia poprawności parametrów wysyłanych przez żądania API — proces, który może być trudny. Jednak konieczne jest, aby testerzy gwarantowali, że wszystkie dane parametrów spełniają kryteria walidacji, takie jak użycie odpowiedniego ciągu lub danych liczbowych, przydzielony zakres wartości oraz zgodność z ograniczeniami długości.

Kombinacja parametrów może być trudna, ponieważ każda kombinacja musi zostać przetestowana, aby sprawdzić, czy zawiera problemy związane z określonymi konfiguracjami. Sekwencjonowanie połączeń jest również wyzwaniem, ponieważ każde połączenie musi pojawić się w określonej kolejności, aby system działał poprawnie. Szybko staje się to wyzwaniem, zwłaszcza w przypadku aplikacji wielowątkowych.

 

Najlepsze praktyki testowania API

 

• Definiując przypadki testowe, pogrupuj je według kategorii.
• Uwzględnij wybrane parametry w samym przypadku testowym.
• Opracuj przypadki testowe dla każdej potencjalnej kombinacji danych wejściowych interfejsu API, aby zapewnić pełne pokrycie testów.
• Ponownie wykorzystuj i powtarzaj przypadki testowe, aby monitorować interfejs API w całej produkcji.
• Używaj zarówno testów ręcznych, jak i automatycznych, aby uzyskać lepsze, bardziej wiarygodne wyniki.
• API powinny być używane do testowania obciążenia systemu.
• Interfejsy API powinny być testowane pod kątem awarii. Testy należy powtarzać, aż do uzyskania nieudanego wyjścia. Interfejs API należy przetestować, aby konsekwentnie nie identyfikował problemów.
• Sekwencjonowanie połączeń powinno być wykonane z solidnym planem.
• Testowanie można ułatwić, ustalając priorytety wywołań funkcji API.
• Korzystaj z dokumentacji na dobrym poziomie, która jest łatwa do zrozumienia i automatyzuj proces tworzenia dokumentacji.
• Jeśli to możliwe, każdy przypadek testowy powinien być samowystarczalny i oddzielony od zależności.

 

Autor: Tomasz Stelmach