Samouczek testowania interfejsu API REST: przykładowe przypadki testowe ręczne

Co to jest testowanie API REST?

Testowanie API REST to technika automatyzacji testowania stron internetowych typu open source, używana do testowania interfejsów API RESTful dla aplikacji internetowych. Celem testowania interfejsu API REST jest rejestrowanie odpowiedzi interfejsu API REST poprzez wysyłanie różnych żądań HTTP/S w celu sprawdzenia, czy interfejs API REST działa poprawnie. Testowanie interfejsu API REST odbywa się za pomocą metod GET, POST, PUT i DELETE.

REST oznacza Representational State Transfer. Jest to styl architektoniczny i podejście do komunikacji stosowane w rozwoju Web ServicesREST stał się logicznym wyborem przy tworzeniu interfejsów API, ponieważ umożliwia użytkownikom efektywne łączenie się i interakcję z usługami w chmurze.

API, czyli Application Programming Interface, to zestaw instrukcji programistycznych umożliwiających dostęp do aplikacji internetowej. Innymi słowy, jest to zestaw poleceń używanych przez jeden program do bezpośredniej komunikacji z innym programem i korzystania z jego funkcji w celu uzyskania informacji.

Na przykład, Google Strona internetowa może mieć interfejs API do wyszukiwania, tłumaczeń i kalendarzy. Ogólnie rzecz biorąc, interfejsy API wyglądają jak poniższy przykład, z nazwą serwera, ścieżkami i parametrami.

http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv

Ale po co w ogóle inwestować wysiłek w testowanie tej warstwy?

Dlaczego testowanie interfejsu API REST ma znaczenie

Interfejs API REST znajduje się pomiędzy interfejsem użytkownika a bazą danych, co czyni go warstwą, w której faktycznie znajduje się większość logiki biznesowej. Błąd w regule cenowej lub sprawdzaniu uprawnień pojawia się w odpowiedzi interfejsu API na długo przed tym, zanim ktokolwiek zauważy błędną liczbę na ekranie, dlatego testowanie w tym miejscu pozwala wykryć problemy wcześniej i bliżej ich przyczyny.

Drugim powodem jest szybkość. Żądanie jest realizowane w milisekundach i nie wymaga przeglądarki, silnika renderującego ani wrażliwych lokalizatorów elementów. Tester może przetestować dziesiątki punktów końcowych w czasie, jaki zajmuje załadowanie strony przez jeden test interfejsu, a to samo żądanie zachowuje się identycznie, niezależnie od tego, czy front-end to strona internetowa, aplikacja mobilna, czy integracja z partnerem.

Stabilność to trzeci powód. Układy zmieniają się nieustannie, ale opublikowany RESTtracOczekuje się, że pozostanie stabilny. Testy opracowane pod kątem tegotracnie przetrwają zmian konstrukcyjnych, więc chronią te części produktu, nad którymi pracują inne zespoły.

Rodzaje metod API

Istnieją głównie 4 rodzaje Testowanie API metody: GET, POST, DELETE i PUT.

• GET– Metoda GET jest używana dotracInformacje z danego serwera za pomocą podanego URI. Podczas korzystania z żądania GET, powinno ono zawierać tylkotracdanych i nie powinno mieć na nie żadnego innego wpływu.
• POST– Do utworzenia nowej jednostki używane jest żądanie POST. Można go również wykorzystać do przesyłania danych na serwer, np. informacji o klientach, przesyłania plików itp. za pomocą formularzy HTML.
• PUT– Utwórz nowy podmiot lub zaktualizuj istniejący.
• DELETE– Usuwa wszystkie bieżące reprezentacje zasobu docelowego podane przez identyfikator URI.

Jak przetestować API REST

Testowanie interfejsu API REST wymaga interakcji aplikacji z przykładowym interfejsem API w celu przeprowadzenia testów. Aby przetestować interfejs API, potrzebne są dwa elementy:

• Narzędzie/rama testowa do obsługi interfejsu API
• Napisanie własnego kodu w celu przetestowania przykładowego API REST

Przypadki testowe interfejsu API REST można testować za pomocą narzędzi takich jak:

• Zaawansowany klient odpoczynku
• Postman-Odpocznij Kliencie
• Curl w Linuksie

W tym przypadku będziemy korzystać z klienta Advanced REST. Poniżej znajdziesz kroki, aby go uruchomić.

Jak zdobyć zaawansowanego klienta REST?

• Iść do Google ChromeSklep internetowy
• Wyszukaj „Advanced Rest Client” lub przejdź bezpośrednio w tym miejscu i Zainstaluj rozszerzenie
• Wybierz ikonę „Zaawansowany klient odpoczynku” w sekcji aplikacji Chrome – chrome://apps/

Lista produktów w sklepie internetowym wygląda tak, jak pokazano poniżej.

Po zakończeniu instalacji wykonaj poniższy test, aby przetestować RESTful API.

Kroki testowania interfejsu API REST

Tutaj używamy rozszerzenia klienta REST w przeglądarce Chrome. Aby lepiej to zrozumieć, do testów używamy fikcyjnego API:

http://ip.jsontest.com/

Krok 1) Otwórz zaawansowanego klienta REST

Uruchom aplikację Zaawansowany klient REST (ARC) po pomyślnym zainstalowaniu.

Krok 2) Wprowadź URL API do testowania

Wprowadź przykładowy interfejs API REST URL do testowania w URL pole tekstowe.

Krok 3) Wybierz metodę HTTP

Wybierz metodę typu metod HTTP w testowaniu API, które mają zostać trafione – np. POST

Krok 4) Podaj zestaw nagłówków

Podaj zestaw nagłówków w polu tekstowym Nagłówki. Kliknij na Wstaw zestaw nagłówków.

Krok 5) Potwierdź ustawienie nagłówków

Następnie kliknij UŻYJ TEGO ZESTAWU.

Krok 6) Podaj wymaganą treść treści

1. Teraz przejdź do zakładki Treść.
2. Ustaw wymagany typ zawartości treści i widok edytora, np. typ zawartości treści: aplikacja/json
3. Widok edytora: surowe dane wejściowe.
4. W sekcji „Payload” przekaż treść żądania API demonstracyjnego do testowania w postaci par klucz-wartość, na przykład {“key1″:”value1″,”key2″:”value2”}. Jeśli jest to API POST, musimy przekazać treść żądania lub parametry. Przekażemy je pod podanym payloadem.

{"property" : ["Sites"], "report_type" : ["ALL"]}

⚠️ Ostrzeżenie: Typ zawartości aplikacji/json z nieprawidłowym ładunkiem JSON zwraca 400 Błędnych żądań.

Krok 7) Prześlij szczegóły, aby rozpocząć test

1. Naciśnij przycisk wysyłania.
2. Aby zobaczyć nagłówki odpowiedzi, kliknij przycisk SZCZEGÓŁY.

Oto szczegóły odpowiedzi:

Odpowiedź nadal musi zostać oceniona w kontekście oczekiwanego rezultatu.

Walidacja wyników

Głównie w przypadku testowania interfejsu API sieciowego musimy sprawdzić kod odpowiedzi, komunikat odpowiedzi i treść odpowiedzi.

Kody odpowiedzi można podzielić na pięć rodzin:

Poniżej znajdują się kody odpowiedzi, z którymi można się spotkać.

Jedno żądanie dowodzi, że punkt końcowy działa. Pakiet dowodzi, że nadal działa.

Przypadki testowe interfejsu API REST, które musisz omówić

Przydatny zestaw REST API obejmuje kilka kategorii zamiast powtarzać to samo wywołanie happy path z różnymi danymi:

• Szczęśliwa ścieżka: Wyślij prawidłowe żądanie do każdego punktu końcowego i potwierdź kod statusu, schemat i wartość każdego pola.
• Przypadki negatywne: Wyślij błędny kod JSON, nieobsługiwaną metodę i brakujący identyfikator zasobu, a następnie oczekuj kodów 400, 405 i 404 zamiast 500.
• Wartości graniczne: Jeśli pole akceptuje od 1 do 200 znaków, przetestuj 0, 1, 200 i 201. Reguły walidacji nie działają na krawędziach.
• Znaki specjalne: Wprowadzaj litery akcentowane, emoji, cudzysłowy i tekst wielobajtowy do każdego pola, aby wykryć błędy kodowania.
• ztract sprawdza: Porównaj odpowiedź ze specyfikacją OpenAPI lub Swagger, aby wykryć nieudokumentowane zmiany na wczesnym etapie.
• Sekwencjonowanie: Wywołuj punkty końcowe w realistycznej kolejności, np. POST, GET, a następnie DELETE, ponieważ stan jest przenoszony między wywołaniami.
• Zdrowy rozsądek w działaniu: Rejestruj czasy reakcji dla każdego przebiegu i sygnalizuj każdy punkt końcowy, który przekracza próg uzgodniony z zespołem.

Narzędzie do testowania interfejsu API REST

Różne narzędzia są odpowiednie dla różnych etapów testowania.

Zobacz podsumowanie Narzędzia do testowania API.

Większość prawdziwych punktów końcowych odmawia odpowiedzi, dopóki żądanie nie zostanie udowodnione, kto je wysłał.

Uwierzytelnianie i kontrole bezpieczeństwa interfejsu API REST

Publiczne punkty końcowe demonstracyjne odpowiadają każdemu, ale produkcyjne API REST opiera się na schemacie uwierzytelniania, a błąd autoryzacji jest o wiele bardziej szkodliwy niż błędna wartość pola. Najpierw zidentyfikuj mechanizm: statyczny klucz API, dane uwierzytelniające HTTP Basic, token nośnika OAuth 2.0 lub podpisany token internetowy JSON.

Gdy uwierzytelnione żądanie zakończy się powodzeniem, należy dokładnie przeanalizować ścieżki błędów:

1. Brak danych uwierzytelniających: Usuń nagłówek Authorization. Spodziewaj się błędu 401 Unauthorized i braku danych rekordu w treści.
2. Nieprawidłowe dane uwierzytelniające: Uszkodzić jeden znak tokena. Spodziewaj się ponownie błędu 401 z komunikatem, który nie wyjaśnia przyczyny.
3. Wygasłe dane uwierzytelniające: Ponowne użycie tokena po upływie jego terminu ważności. Potwierdź, że został on odrzucony, a nie uznany – częsty błąd zegara.
4. Nieprawidłowy poziom uprawnień: Uwierzytelnij się jako użytkownik o niskich uprawnieniach i wywołaj punkt końcowy dostępny tylko dla administratora. Spodziewaj się błędu 403 Forbidden, a nie 200.
5. Rekord innego użytkownika: Zmień ID tak, aby użytkownik A zażądał danych użytkownika B. Sukces w tym przypadku jest poważną wadą kontroli dostępu.

Na koniec sprawdź, czy każde wywołanie jest przesyłane przez HTTPS i czy nieudane odpowiedzi nie powodują wycieku stosu traces lub banery wersji i szybkie powtarzanie wyzwalają 429 Zbyt wiele żądań.

Testowanie interfejsu API REST wiąże się również z trudnościami, których nie ma w przypadku testowania interfejsów.

Wyzwania związane z testowaniem API

Interesujące problemy dla testerów podczas testowania interfejsu REST API to:

1. Aby upewnić się, że system testowy zmienia parametry wywołań API w taki sposób, aby weryfikować funkcjonalność i wykrywać awarie. Obejmuje to badanie warunków brzegowych i przypisywanie wspólnych parametrów.
2. Tworzenie interesujących kombinacji wartości parametrów dla wywołań z dwoma lub większą liczbą parametrów
3. Określenie zawartości, w ramach której muszą być wykonywane wywołania API. Może to obejmować ustawienie warunków środowiska zewnętrznego (urządzeń peryferyjnych, plików itp.), a także danych przechowywanych wewnętrznie, które wpływają na API.
4. Sekwencjonowanie wywołań API zgodnie z kolejnością wykonywania funkcji
5. Aby interfejs API generował przydatne wyniki z kolejnych wywołań.

FAQ