api testing tutorial
W tym szczegółowym samouczku testowania interfejsu API wyjaśniono wszystko o testowaniu interfejsów API, usługach sieci Web i sposobach wprowadzenia testowania interfejsu API w organizacji:
Uzyskaj głęboki wgląd w testowanie interfejsu API wraz z koncepcją testowania z przesunięciem w lewo i usługami sieciowymi z tego samouczka wprowadzającego.
Pojęcia takie jak interfejs API sieci Web, sposób działania interfejsu API (na przykładzie świata rzeczywistego) i czym różni się od usług sieci Web są dobrze wyjaśnione za pomocą przykładów w tym samouczku.
=>PRZEWIŃ W DÓŁaby zobaczyć całą listę 5 szczegółowych samouczków testowania API dla początkujących
Czego się nauczysz:
- Lista samouczków testowania API
- Przegląd samouczków w tej serii testów API
- Samouczek testowania API
- Przedstawiamy testowanie API w Twojej organizacji
- Wniosek
Lista samouczków testowania API
Samouczek nr 1: Samouczek testowania interfejsu API: kompletny przewodnik dla początkujących
Samouczek nr 2: Samouczek dotyczący usług internetowych: składniki, architektura, typy i przykłady
Samouczek nr 3: 35 najczęściej zadawanych pytań dotyczących ASP.Net i interfejsu API sieci Web z odpowiedziami
Samouczek nr 4: Samouczek POSTMAN: Testowanie API przy użyciu POSTMAN
Samouczek nr 5: Testowanie usług internetowych przy użyciu klienta Apache HTTP
Przegląd samouczków w tej serii testów API
Instruktaż # | Czego się nauczysz | |
---|---|---|
LoadFocus | Na podstawie liczby użytkowników i typów planów | * Może być używany do testowania obciążenia API - umożliwia przeprowadzenie kilku testów, aby dowiedzieć się, ilu użytkowników może obsługiwać interfejs API. * Prosty w użyciu - umożliwia uruchamianie testów w przeglądarce. |
Tutorial_ # 1: | Samouczek testowania interfejsu API: kompletny przewodnik dla początkujących Ten szczegółowy samouczek dotyczący testowania interfejsu API szczegółowo wyjaśni wszystkie zagadnienia związane z testowaniem interfejsów API i usługami sieciowymi, a także nauczy Cię, jak wprowadzić testowanie interfejsu API w Twojej organizacji. | |
Tutorial_ # 2: | Samouczek dotyczący usług internetowych: składniki, architektura, typy i przykłady Ten samouczek dotyczący usług internetowych wyjaśnia architekturę, typy i składniki usług internetowych, a także ważne terminologie i różnice między protokołem SOAP a REST. | |
Tutorial_ # 3: | 35 najczęściej zadawanych pytań dotyczących ASP.Net i interfejsu API sieci Web z odpowiedziami W tym samouczku możesz zapoznać się z listą najczęściej zadawanych pytań wywiadowczych dotyczących ASP.Net i interfejsu API sieci Web wraz z odpowiedziami i przykładami dla początkujących i doświadczonych profesjonalistów. | |
Tutorial_ # 4: | Samouczek POSTMAN: Testowanie API przy użyciu POSTMAN Ten samouczek krok po kroku objaśni testowanie API przy użyciu POSTMAN wraz z podstawami programu POSTMAN, jego komponentami oraz przykładowym żądaniem i odpowiedzią w prosty sposób, aby ułatwić zrozumienie. | |
Tutorial_ # 5: | Testowanie usług internetowych przy użyciu klienta Apache HTTP Ten samouczek dotyczący interfejsu API dotyczy wykonywania różnych operacji CRUD w usługach sieci Web i testowania usług sieci Web przy użyciu klienta Apache HTTP |
Samouczek testowania API
Ta sekcja pomoże Ci uzyskać podstawową wiedzę na temat usług sieci Web i interfejsu API sieci Web, co z kolei będzie pomocne w zrozumieniu głównych pojęć w nadchodzących samouczkach w tej serii testów interfejsu API.
API (Application Programming Interface) to zestaw wszystkich procedur i funkcji, które pozwalają nam stworzyć aplikację poprzez dostęp do danych lub funkcji systemu operacyjnego lub platform. Testowanie takich procedur jest znane jako testowanie API.
Przesuń w lewo testowanie
Jednym z ważnych rodzajów testów, o które w dzisiejszych czasach zadaje się w wywiadach z testowaniem API, jest testowanie z przesunięciem w lewo. Ten rodzaj testowania jest praktykowany w prawie wszystkich projektach, które są zgodne z metodologią Agile.
Przed wprowadzeniem Shift Left Testing, testowanie oprogramowania pojawiło się dopiero po zakończeniu kodowania i dostarczeniu kodu do testerów. Ta praktyka doprowadziła do krzątaniny w ostatniej chwili, aby dotrzymać terminu, a także w znacznym stopniu obniżyła jakość produktu.
Poza tym wysiłki podjęte (kiedy usterki zostały zgłoszone w ostatniej fazie przed produkcją) były ogromne, ponieważ programiści musieli od nowa przechodzić zarówno przez fazę projektowania, jak i kodowania.
Cykl życia rozwoju oprogramowania (SDLC) przed testowaniem w lewo
Tradycyjny przepływ SDLC to: Wymagania -> Projekt -> Kodowanie -> Testowanie.
Wady tradycyjnego testowania
- Testowanie jest skrajnie słuszne. Gdy błąd zostanie zidentyfikowany w ostatniej chwili, ponosi się wiele kosztów.
- Czas poświęcony na naprawę błędu i ponowne przetestowanie go przed promocją do produkcji jest ogromny.
W związku z tym pojawił się nowy pomysł, aby przesunąć fazę testowania w lewo, co w ten sposób doprowadziło do przesunięcia w lewo testowania.
Sugerowany odczyt => Shift Left Testing: Sekretna mantra sukcesu oprogramowania
Fazy testowania lewostronnego przesunięcia
Testowanie z lewą zmianą doprowadziło do pomyślnej migracji z wykrywania defektów do zapobiegania defektom. Pomogło również oprogramowaniu szybko zawieść i naprawić wszystkie awarie najwcześniej.
Internetowy interfejs API
Ogólnie rzecz biorąc, interfejs API sieci Web można zdefiniować jako coś, co przenosi żądanie z systemu klienta na serwer sieci Web i odsyła odpowiedź z serwera sieci Web na komputer kliencki.
Jak działa API?
Przyjrzyjmy się bardzo częstemu scenariuszowi rezerwacji lotu w witrynie www.makemytrip.com, która jest internetową usługą turystyczną, która gromadzi informacje z wielu linii lotniczych. Wybierając się do rezerwacji lotu, wpisujesz takie informacje, jak data podróży / data powrotu, klasa itp., A następnie kliknij przycisk wyszukiwania.
Spowoduje to wyświetlenie ceny wielu linii lotniczych i ich dostępności. W takim przypadku aplikacja współdziała z interfejsami API wielu linii lotniczych, umożliwiając tym samym dostęp do danych linii.
Innym przykładem jest witryna www.trivago.com, która porównuje i podaje ceny, dostępność itp. Różnych hoteli w danym mieście. Ta strona internetowa komunikuje się z interfejsami API wielu hoteli w celu uzyskania dostępu do bazy danych i podaje ceny i dostępność w ich witrynach internetowych.
W ten sposób interfejs API sieci Web można zdefiniować jako „interfejs, który ułatwia komunikację między komputerem klienckim a serwerem sieciowym”.
Usługi internetowe
Usługi internetowe to (podobnie jak interfejs API sieci Web) usługi, które obsługują z jednej maszyny na drugą. Jednak główna różnica między API a usługami sieciowymi polega na tym, że usługi internetowe korzystają z sieci.
Można śmiało powiedzieć, że wszystkie usługi internetowe są interfejsami API sieci Web, ale wszystkie interfejsy API sieci Web nie są usługami sieciowymi (wyjaśniono w dalszej części artykułu). Dlatego usługi sieci Web są podzbiorem interfejsu API sieci Web. Zapoznaj się z poniższym diagramem, aby dowiedzieć się więcej o interfejsie API sieci Web i usługach sieci Web.
Interfejs API sieci Web a usługi internetowe
Usługi sieciowe a interfejs API sieci Web
W celu ułatwienia komunikacji między klientem a serwerem używane są zarówno Web API, jak i Web Services. Główna różnica dotyczy tylko sposobu, w jaki się komunikują.
Każdy z nich wymaga treści żądania akceptowalnej w określonym języku, różnic w zapewnianiu bezpiecznego połączenia, szybkości komunikacji z serwerem i odpowiedzi zwrotnej klientowi itp.
Różnice między usługami sieciowymi a interfejsem API sieci Web są wymienione poniżej w celach informacyjnych.
Serwis internetowy
- Usługi sieci Web na ogół używają języka XML (Extensible Markup Language), co oznacza, że są bezpieczniejsze.
- Usługi sieci Web są bezpieczniejsze, ponieważ zarówno usługi sieci Web, jak i interfejsy API zapewniają protokół SSL (Secure Socket Layer) podczas transmisji danych, ale zapewniają również WSS (Bezpieczeństwo usług internetowych).
- Usługa internetowa to podzbiór interfejsu API sieci Web. Na przykład, Usługi internetowe są oparte tylko na trzech stylach użytkowania, tj. SOAP, REST i XML-RPC.
- Usługi sieciowe zawsze wymagają do działania sieci.
- Usługi sieci Web obsługują „Jeden kod dla różnych aplikacji”. Oznacza to, że bardziej ogólny kod jest napisany w różnych aplikacjach.
Internetowy interfejs API
- Interfejs API sieci Web na ogół używa formatu JSON (JavaScript Object Notation), co oznacza, że interfejs API sieci Web jest szybszy.
- Interfejs API sieci Web jest szybszy, ponieważ JSON jest lekki, w przeciwieństwie do XML.
- Interfejsy API sieci Web to nadzbiór usług internetowych. Na przykład, Wszystkie trzy style usług sieciowych są również obecne w interfejsie API sieci Web, ale oprócz tego używa innych stylów, takich jak JSON - RPC.
- Interfejs API sieci Web niekoniecznie wymaga sieci do działania.
- Interfejs API sieci Web może obsługiwać współdziałanie lub nie, w zależności od charakteru systemu lub aplikacji.
Przedstawiamy testowanie API w Twojej organizacji
W naszym codziennym życiu wszyscy jesteśmy przyzwyczajeni do interakcji z aplikacjami za pomocą interfejsów API, a mimo to nawet nie myślimy o procesach zaplecza, które sterują podstawową funkcjonalnością.
Na przykład, Rozważmy, że przeglądasz produkty na Amazon.com i widzisz produkt / ofertę, która naprawdę Ci się podoba i chcesz się nią podzielić ze swoją siecią Facebook.
W momencie, gdy klikniesz ikonę Facebooka w sekcji udostępniania strony i wprowadzisz dane logowania do konta na Facebooku, aby je udostępnić, wchodzisz w interakcję z API, które płynnie łączy witrynę Amazon z Facebookiem.
Skoncentruj się na testowaniu API
Zanim omówimy więcej na temat testowania API, omówmy powody, dla których aplikacje oparte na API zyskały ostatnio popularność.
Istnieje kilka powodów, dla których organizacje przechodzą na produkty i aplikacje oparte na API. Kilka z nich jest wymienionych poniżej w celach informacyjnych.
# 1) Aplikacje oparte na API są bardziej skalowalne w porównaniu z tradycyjnymi aplikacjami / oprogramowaniem. Tempo tworzenia kodu jest szybsze, a ten sam interfejs API może obsługiwać więcej żądań bez większych zmian w kodzie lub infrastrukturze.
#dwa) Zespoły programistyczne nie muszą zaczynać programowania od zera za każdym razem, gdy zaczynają pracę nad opracowaniem funkcji lub aplikacji. Interfejsy API najczęściej ponownie wykorzystują istniejące, powtarzalne funkcje, biblioteki, procedury składowane itp., A zatem ten proces może ogólnie zwiększyć ich produktywność.
Na przykład, Jeśli jesteś programistą pracującym na stronie e-commerce i chcesz dodać Amazon jako procesor płatności - nie musisz pisać kodu od zera.
Wszystko, co musisz zrobić, to skonfigurować integrację między swoją witryną a Amazon API za pomocą kluczy integracyjnych i zadzwonić do Amazon API do przetwarzania płatności podczas płatności.
# 3) Interfejsy API umożliwiają łatwą integrację z innymi systemami zarówno w przypadku obsługiwanych samodzielnych aplikacji, jak i produktów oprogramowania opartych na API.
Na przykład , Rozważmy, że chcesz wysłać przesyłkę z Toronto do Nowego Jorku. Wchodzisz do trybu online, przechodzisz do dobrze znanej witryny frachtu lub logistyki i wprowadzasz wymagane informacje.
Po podaniu obowiązkowych informacji, po kliknięciu przycisku Pobierz stawki - na zapleczu ta witryna logistyczna może łączyć się z kilkoma interfejsami API i aplikacjami przewoźników i usługodawców, aby uzyskać dynamiczne stawki dla kombinacji lokalizacji pochodzenia do miejsca docelowego.
Pełne spektrum testów API
Testowanie API nie ogranicza się do wysłania żądania do API i analizy odpowiedzi pod kątem samej poprawności. Interfejsy API należy przetestować pod kątem ich wydajności przy różnych obciążeniach pod kątem luk w zabezpieczeniach.
Omówmy to szczegółowo.
(i) Testy funkcjonalne
Testowanie funkcjonalne może być trudnym zadaniem ze względu na brak interfejsu GUI.
Zobaczmy, jak podejście do testowania funkcjonalnego for API różni się od aplikacji opartej na GUI i omówimy również kilka przykładów dotyczących tego.
do) Najbardziej oczywistą różnicą jest to, że nie ma GUI, z którym można by współdziałać. Testerom, którzy zwykle przeprowadzają testy funkcjonalne w oparciu o GUI, nieco trudniej jest przejść do testów aplikacji innych niż GUI w porównaniu z kimś, kto już je zna.
Początkowo, jeszcze zanim zaczniesz testować API, będziesz musiał przetestować i zweryfikować sam proces uwierzytelniania. Metoda uwierzytelniania będzie się różnić w zależności od jednego interfejsu API do drugiego i wymagałaby użycia klucza lub tokenu do uwierzytelnienia.
Jeśli nie możesz pomyślnie połączyć się z interfejsem API, dalsze testy nie mogą być kontynuowane. Ten proces można uznać za porównywalny z uwierzytelnianiem użytkownika w standardowych aplikacjach, w których wymagane są ważne poświadczenia, aby zalogować się i korzystać z aplikacji.
b) Testowanie walidacji pól lub walidacji danych wejściowych jest bardzo ważne podczas testowania interfejsów API. Jeśli dostępny był rzeczywisty interfejs oparty na formularzach (GUI), wówczas walidacje pól można by zaimplementować w interfejsie użytkownika lub zapleczu, zapewniając w ten sposób, że użytkownik nie będzie mógł wprowadzać nieprawidłowych wartości pól.
Na przykład, Jeśli aplikacja wymaga formatu daty DD / MM / RRRR, możemy zastosować tę walidację do formularza zbierającego informacje, aby upewnić się, że wniosek otrzymuje i przetwarza prawidłową datę.
To jednak nie to samo w przypadku aplikacji API. Musimy upewnić się, że API jest dobrze napisane i jest w stanie wymusić wszystkie te walidacje, rozróżnić prawidłowe i nieprawidłowe dane oraz zwrócić kod statusu i komunikat o błędzie walidacji do użytkownika końcowego za pośrednictwem odpowiedzi.
do) Testowanie poprawności odpowiedzi z API pod kątem prawidłowych i nieprawidłowych odpowiedzi jest rzeczywiście kluczowe. Jeśli jako odpowiedź z testowego interfejsu API zostanie odebrany kod statusu 200 (co oznacza, że wszystko w porządku), ale tekst odpowiedzi mówi, że napotkano błąd, oznacza to usterkę.
Dodatkowo, jeśli sam komunikat o błędzie jest nieprawidłowy, może to być bardzo mylące dla klienta końcowego, który próbuje zintegrować się z tym interfejsem API.
Na poniższym zrzucie ekranu użytkownik wprowadził nieprawidłową wagę, która jest większa niż dopuszczalne 2267 kg. Interfejs API odpowiada kodem statusu błędu i komunikatem o błędzie. Jednak komunikat o błędzie nieprawidłowo wymienia jednostki masy jako funty zamiast KG. Jest to wada, która może zmylić klienta końcowego.
(ii) Testy obciążenia i wydajności
Interfejsy API mają być skalowalne z założenia.
To z kolei sprawia, że Load i Test wydajności niezbędne, zwłaszcza jeśli projektowany system ma obsługiwać tysiące żądań na minutę lub godzinę, w zależności od wymagań. Rutynowe przeprowadzanie testów obciążenia i wydajności w interfejsie API może pomóc w ocenie wydajności, szczytowych obciążeń i punktu zerwania.
Te dane są przydatne podczas planowania skalowania aplikacji. Posiadanie tych informacji pomoże w podejmowaniu decyzji i planowaniu, zwłaszcza jeśli organizacja planuje dodać więcej klientów, co oznaczałoby więcej przychodzących żądań.
Na przykład Załóżmy, że na podstawie przedstawionych wymagań wiemy, że zaprojektowany interfejs API musi obsługiwać co najmniej 500 żądań na godzinę i utrzymywać średni czas odpowiedzi poniżej 0,01 sekundy.
Na podstawie naszych testów obciążenia i wydajności odkryliśmy, że dopóki API otrzymuje mniej niż 500 żądań na godzinę, jest w stanie utrzymać SLA dla średniego czasu odpowiedzi. Jeśli jednak otrzyma kolejne 200 żądań, średni czas odpowiedzi wzrośnie, a punkt przerwania zostanie osiągnięty, gdy przychodzące żądanie przekroczy 1200 na godzinę.
Zwykle widać, że na początkowych etapach projektowania często kładzie się nacisk na funkcjonalne aspekty API. Z biegiem czasu produkt zaczyna obsługiwać wielu aktywnych klientów, czyli wtedy, gdy testy wydajności API i testy obciążenia pojawiają się w bardziej rutynowy sposób.
(iii) Testowanie bezpieczeństwa
Interfejsy programowania aplikacji lub interfejsy API są podatne na ataki i stanowią najłatwiejszy punkt dostępu dla złośliwych hakerów, którzy chcą uzyskać dostęp do danych lub przejąć kontrolę nad aplikacją.
Może to doprowadzić każdą firmę do problemów prawnych, w przypadku których z powodu naruszenia bezpieczeństwa niezamierzone osoby i / lub organizacje mogą uzyskać dostęp do danych klienta za pośrednictwem szacownego interfejsu API.
Testy bezpieczeństwa to wyspecjalizowana gałąź testowania i powinna być obsługiwana przez specjalistów. Zasoby do testowania bezpieczeństwa mogą pochodzić z organizacji lub niezależnych konsultantów.
implementacja tablicy skrótów c ++
Przeczytaj także = >> Co to jest testowanie umów paktowych
Jak wprowadzić testowanie API w swojej organizacji
Proces wprowadzania testów API w dowolnej organizacji jest podobny do procesu używanego do wdrażania lub wdrażania dowolnego innego narzędzia testowego i frameworka.
Poniższa tabela zawiera podsumowanie głównych kroków wraz z oczekiwanym wynikiem każdego etapu.
Faza | Krok | Spodziewany rezultat |
---|---|---|
Wybór narzędzia | Zbierz wymagania i zidentyfikuj ograniczenia | Zrozum wymagania dotyczące badania rynku pod kątem odpowiedniego narzędzia testowego API. Na przykład. Jaki rodzaj API jest testowany - SOAP czy REST? Czy musimy zatrudniać testera do tej roli, czy też szkolić istniejącego testera? Jakie testy będą wykonywane - testy funkcjonalne, wydajnościowe itp. Jaki jest budżet na realizację? |
Oceń dostępne narzędzia | Porównaj dostępne narzędzia i listę 1 lub 2 narzędzi, które najlepiej spełniają wymagania. | |
Dowód koncepcji | Zaimplementuj podzbiór testów za pomocą wybranego narzędzia. Przedstaw ustalenia zainteresowanym stronom. Sfinalizuj narzędzie do wdrożenia. | |
Realizacja | Pierwsze kroki | W zależności od wybranego narzędzia, nie musisz instalować wymaganego narzędzia na komputerze PC, maszynie wirtualnej lub serwerze. Jeśli wybrane narzędzie jest oparte na subskrypcji, utwórz wymagane konta zespołu. W razie potrzeby przeszkol zespół. |
Wyruszyć | Twórz testy Wykonaj testy Zgłoś usterki |
Typowe wyzwania i sposoby ich złagodzenia
Omówmy niektóre z typowych wyzwań, z którymi borykają się zespoły kontroli jakości, próbując wdrożyć ramy testowania API w organizacji.
# 1) Wybór odpowiedniego narzędzia
Wybór odpowiedniego narzędzia do pracy jest najczęstszym wyzwaniem. Na rynku dostępnych jest kilka narzędzi do testowania API.
Wdrożenie najnowszego, najdroższego narzędzia dostępnego na rynku może wydawać się bardzo atrakcyjne - ale jeśli nie przynosi oczekiwanych rezultatów, to narzędzie jest bezużyteczne.
Dlatego zawsze wybieraj narzędzie, które spełnia „niezbędne” wymagania w oparciu o potrzeby Twojej organizacji.
Oto przykładowa macierz oceny narzędzi dla dostępnych narzędzi API
Narzędzie | cennik | Uwagi |
---|---|---|
Soap UI | Darmowa wersja dostępna dla SoapUI Open Source (testy funkcjonalne) | * REST, SOAP i inne popularne protokoły API i IoT. * Zawarte w bezpłatnej wersji Testowanie ad-hoc SOAP i REST Potwierdzenie wiadomości Tworzenie testów metodą przeciągnij i upuść Dzienniki testów Konfiguracja testowa Test z nagrań Raportowanie jednostek. * Pełną listę funkcji można znaleźć na ich stronie internetowej. |
Listonosz | Dostępna jest bezpłatna aplikacja Listonosz | * Najczęściej używany do REST. * Funkcje można znaleźć na ich stronie internetowej. |
Parasoft | Jest to płatne narzędzie, które wymaga zakupu licencji, a następnie instalacji, zanim będzie można z niego korzystać. | * Kompleksowe testy API: testy funkcjonalne, obciążeniowe, bezpieczeństwa, zarządzanie danymi testowymi |
vREST | Na podstawie liczby użytkowników | * Automatyczne testowanie REST API. * Nagrywaj i odtwarzaj. * Usuwa zależności od frontendu i backendu za pomocą fałszywych interfejsów API. * Potężna walidacja odpowiedzi. * Działa dla aplikacji testowych wdrożonych na hoście lokalnym / intranecie / internecie. * JIRA Integration, Jenkins Integration Imports from Swagger, Postman. |
HttpMaster | Express Edition: do pobrania bezpłatnie Wersja profesjonalna: na podstawie liczby użytkowników | * Pomaga w testowaniu stron internetowych, a także testowaniu API. * Inne funkcje obejmują możliwość definiowania parametrów globalnych, zapewniają użytkownikowi możliwość tworzenia sprawdzeń sprawdzania poprawności odpowiedzi na dane przy użyciu dużego zestawu obsługiwanych typów walidacji. |
Runscope | Na podstawie liczby użytkowników i typów planów | * Do monitorowania i testowania interfejsów API. * Może służyć do sprawdzania poprawności danych, aby zapewnić zwrócenie prawidłowych danych. * Zawiera funkcję śledzenia i powiadamiania w przypadku niepowodzenia transakcji API (jeśli Twoja aplikacja wymaga weryfikacji płatności, to narzędzie to może okazać się dobrym wyborem). |
PingAPI | Bezpłatnie dla 1 projektu (1000 żądań) | * Korzystne dla zautomatyzowanego testowania i monitorowania API. |
# 2) Brak specyfikacji testu
Jako testerzy musimy znać oczekiwane wyniki, aby skutecznie przetestować aplikację. Często jest to wyzwanie, ponieważ aby poznać oczekiwane wyniki, musimy mieć jasne, precyzyjne wymagania - co nie jest prawdą.
Na przykład , weź pod uwagę wymagania podane poniżej:
„Aplikacja powinna akceptować tylko prawidłową datę wysyłki, a wszystkie nieprawidłowe wymagania powinny zostać odrzucone”
W wymaganiach tych brakuje kluczowych szczegółów i są one bardzo niejednoznaczne - jak definiujemy prawidłową datę? A co z formatem? Czy odsyłamy wiadomość o odrzuceniu do użytkownika końcowego itp.?
Przykład wyraźnych wymagań:
1) Aplikacja powinna akceptować tylko prawidłową datę wysyłki.
Datę wysyłki uważa się za ważną, jeśli tak jest
- Nie w przeszłości
- Większa lub równa dzisiejszej dacie
- Ma dopuszczalny format: DD / MM / RRRR
dwa)
Kod stanu odpowiedzi = 200
Wiadomość: OK
3) Datę wysyłki, która nie spełnia powyższych kryteriów, należy uznać za nieważną. Jeśli klient prześle nieprawidłową datę wysyłki, musi odpowiedzieć następującymi komunikatami o błędzie:
3.1
Kod stanu odpowiedzi NIE 200
Błąd: podana data wysyłki jest nieprawidłowa; upewnij się, że data jest w formacie DD / MM / RRRR
3.2
Kod stanu odpowiedzi NIE 200
Błąd: podana data wysyłki już minęła
# 3) Krzywa uczenia się
Jak wspomniano wcześniej, podejście do testowania API jest inne niż podejście stosowane podczas testowania aplikacji opartych na GUI.
Jeśli zatrudniasz specjalistów lub konsultantów do testowania API, krzywa uczenia się podejścia do testowania API lub narzędzia testowego API może być minimalna. Każda krzywa uczenia się w tym przypadku wiązałaby się ze zdobyciem wiedzy o produkcie lub aplikacji.
Jeśli istniejący członek zespołu ma uczyć się testowania API, to w zależności od wybranego narzędzia krzywa uczenia się może być średnia do wysokiej, wraz ze zmianą podejścia do testowania. Krzywa uczenia się dla samego produktu lub aplikacji może być niska-średnia, w zależności od tego, czy ten tester testował tę aplikację wcześniej, czy nie.
# 4) Istniejący zestaw umiejętności
Wiąże się to bezpośrednio z poprzednim punktem dotyczącym krzywej uczenia się.
Jeśli tester przechodził z testowania opartego na GUI, musiałby zmienić podejście do testowania i nauczyć się nowego narzędzia lub struktury zgodnie z wymaganiami. Na przykład. Jeśli API akceptuje żądania w formacie JSON, tester musiałby dowiedzieć się, czym jest JSON, aby rozpocząć tworzenie testów.
Studium przypadku
Zadanie
Aby zwiększyć skalę istniejącej aplikacji, firma chciała zaoferować produkt w API, a także standardową aplikację GUI. Zespół ds. Kontroli jakości został poproszony o dostarczenie planu pokrycia testów, aby upewnić się, że jest gotowy do przeprowadzania testów API poza zwykłymi testami opartymi na graficznym interfejsie użytkownika.
Wyzwania
- Żaden z pozostałych produktów oprogramowania nie miał architektury opartej na API, dlatego aby umożliwić testowanie wokół tego zadania, zespół musi opracować proces testowania API od podstaw. Oznacza to, że narzędzia miały zostać ocenione, zakwalifikowane do krótkiej listy, sfinalizowane, a zespół musiał zostać przeszkolony do testów.
- Nie przewidziano dodatkowego budżetu na pozyskanie i wdrożenie narzędzia. Oznacza to, że zespół musiał wybrać bezpłatne lub otwarte narzędzie do testowania API, a ktoś z istniejącego zespołu musiał zostać przeszkolony do wykonania tego zadania.
- Nie było wymagań dotyczących pól API i walidacji danych. Wymagania brzmiały: „powinny działać tak samo, jak odpowiednia aplikacja GUI”.
Podejście zastosowane przez zespół do ograniczania ryzyka i radzenia sobie z wyzwaniami
- Zespół ds. Kontroli jakości współpracował z zespołem projektowym, aby zidentyfikować następujące wymagania:
- Typ API (REST / SOAP): ODPOCZYNEK
- Wymagane testy (funkcjonalne, obciążeniowe, bezpieczeństwa): Tylko testy funkcjonalne
- Wymagane testy automatyczne (tak / nie): Na razie opcjonalne
- Raporty z testów (tak / nie): wymagany
- Zespół ds. Kontroli jakości przeprowadził ocenę dostępnych narzędzi Narzędzia do testowania API w oparciu o niezbędne wymagania. Narzędzie Postman API zostało ostatecznie wybrane jako wybrane przez nich narzędzie, ponieważ było bezpłatne i łatwe w użyciu, minimalizując w ten sposób krzywą uczenia się i miało potencjał do automatyzacji testów oraz zawierało dobre wbudowane raporty.
- Ten sam tester, który testował aplikację, został przeszkolony w zakresie używania programu Postman do tworzenia wstępnych testów, eliminując tym samym wszelkie luki w wiedzy o produkcie.
- Aby poradzić sobie z brakującymi wymaganiami, zespół projektowy stworzył dokumentację wysokiego poziomu w terenie przy użyciu oprogramowania Swagger. To jednak pozostawiło pewne luki w zakresie dopuszczalnych formatów danych, które zostały omówione przez zespół projektowy, a oczekiwane formaty zostały uzgodnione i udokumentowane.
Wniosek
Aplikacje oparte na API zyskały ostatnio popularność. Aplikacje te są bardziej skalowalne w porównaniu z tradycyjnymi aplikacjami / oprogramowaniem i umożliwiają łatwiejszą integrację z innymi interfejsami API lub aplikacjami.
W tym samouczku testowania interfejsu API szczegółowo wyjaśniono wszystkie zagadnienia dotyczące testowania interfejsu API, testowania w lewo, usług sieci Web i interfejsu API sieci Web. Na przykładach zbadaliśmy również różnice między usługami sieciowymi a interfejsem API sieci Web.
W drugiej części samouczka omówiliśmy pełne spektrum testów API, jak wprowadzić testowanie API w Twojej organizacji oraz kilka typowych wyzwań w tym procesie wraz z rozwiązaniami dla nich.
Zapoznaj się z nadchodzącym samouczkiem, aby dowiedzieć się więcej o usługach internetowych wraz z przykładami!
rekomendowane lektury
- Testy alfa i testy beta (kompletny przewodnik)
- Testy funkcjonalne a testy niefunkcjonalne
- Samouczek testowania użyteczności: kompletny przewodnik dla początkujących
- Kompletny przewodnik po testach weryfikacyjnych kompilacji (testy BVT)
- Samouczek testowania DevOps: Jak DevOps wpłynie na testy QA?
- Samouczek testowania dostępności (kompletny przewodnik krok po kroku)
- Najlepsze narzędzia do testowania oprogramowania 2021 [Narzędzia do automatyzacji testów QA]
- Co to jest testowanie oprogramowania? Ponad 100 darmowych samouczków do testowania ręcznego