Samouczki i przykłady ReadyAPI (1)

Readyapi Tutorials Examples

Zastrzeżenie: Jeśli chcesz przedrukować, podaj link do tego bloga, uszanuj oryginał, dziękuję!

Wersja ReadyAPI używana w tym artykule to 2.5.0.

Oto krótki przegląd funkcji SoapUI w głównym ReadyAPI:

Najpierw utwórz test funkcjonalny

Użytkownicy mogą łatwo przeprowadzać testy funkcjonalne, obciążeniowe i bezpieczeństwa usług internetowych przy użyciu ReadyAPI. Użytkownicy mogą również tworzyć lokalną wirtualną kopię usługi, aby przeprowadzać testy, zanim prawdziwa usługa zostanie uruchomiona.

W tym artykule opisano, jak tworzyć podstawowe testy funkcjonalne w SoapUI. Załadujemy definicję usługi sieciowej z pliku, utworzymy test dla operacji, uruchomimy test i użyjemy asercji do walidacji wyników testu.

Ten artykuł zawiera następujące informacje:

1, podstawowa koncepcja

2, utwórz test funkcjonalny

3. Zapoznaj się z projektem projektu testowego

4, zmodyfikuj test SoapUI

5, uruchom test SoapUI

6, dodaj potwierdzenia

1 ,podstawowy pomysł

Aby tworzyć i uruchamiać testy przy użyciu ReadyAPI, użytkownicy potrzebują ogólnej wiedzy na temat technologii usług internetowych i zasad testowania. Ten temat jest bardzo obszerny i wykracza poza zakres dokumentacji ReadyAPI, a użytkownicy mogą znaleźć w sieci wiele doskonałych zasobów wyjaśniających te techniki. Tutaj właśnie napisaliśmy przegląd, aby pomóc użytkownikom szybciej rozpocząć korzystanie z ReadyAPI.

1.1 ,podstawowa wiedza

Usługa sieciowa to aplikacja typu klient / serwer, w której klient i serwer wymieniają dane przez sieć WWW za pośrednictwem protokołu HTTP lub innych protokołów opartych na protokole HTTP. Przykłady takich aplikacji obejmują oprogramowanie nawigacyjne, klientów bankowości internetowej, systemy monitorowania pogody i tym podobne.

Adres URL, który klient wysyła żądanie, zawiera: informacje o testowanym serwerze (host), numer portu używanego do komunikacji oraz żądany zasób serwera, taki jak strona lub ścieżka do pliku:

Komunikat żądania wysłany przez klienta do serwera ma następującą strukturę:

Linia początkowa: określ linię początkową metody HTTP (np. GET, POST lub DELETE), docelowy adres URL i wersję protokołu.

Nagłówek: podaj dodatkowe informacje, takie jak oczekiwany format danych odpowiedzi lub rozmiar i format żądanych danych.

Treść wiadomości: (opcjonalnie) niektóre typy żądań jej nie używają.

Wiadomość z odpowiedzią ma podobną strukturę:

Wiersz początkowy: z kodem odpowiedzi i komunikatem, niektóre typowe kody to 200 OK (powodzenie), 404 Not Found (niepowodzenie, nie można znaleźć żądanego zasobu) i 504 (błąd wewnętrzny serwera).

Nagłówek: opisuje format danych odpowiedzi i zawiera inne wartości (takie jak pliki cookie, informacje o serwerze itp.).

Treść wiadomości: treść odpowiedzi zawiera tablicę obrazów, obrazów, plików i tak dalej.

Typowe formaty treści żądań i odpowiedzi to JSON i XML.

Polecenia, które klient wysyła do serwera w celu wykonania, nazywane są akcjami, metodami lub operacjami, w zależności od stylu architektury usługi (SOAP lub REST, patrz poniżej).

Dwa popularne style architektoniczne dla usług internetowych to SOAP i REST:

Usługa SOAP korzysta z protokołu SOAP zbudowanego przez HTTP. Te usługi używają żądań HTTP typu POST i przekazują dane w formacie XML w treści żądań i odpowiedzi. Wszystkie żądania trafiają do tego samego adresu URL, a czynność do wykonania jest określona przez specjalny nagłówek żądania lub element XML w treści żądania.

Usługi SOAP używają definicji WSDL do ścisłego opisywania operacji obsługiwanych przez usługę, typów parametrów i formatów danych.

Usługa REST działa za pośrednictwem protokołu HTTP. Operacja do wykonania jest ustawiana przez kombinację metody HTTP i żądanej nazwy zasobu. Na przykład usługa RESTful dla internetowego sklepu zoologicznego może mieć zasób / Pets. Żądanie POST http://petstore.io/pets może dodać informacje o zwierzętach do bazy danych, a żądanie GET http://petstore.io/pets może pobrać informacje o dostępnych zwierzętach.

Istnieje kilka formatów definicji usług REST: OpenAPI (Swagger), WADL i inne formaty. Ale niektórzy programiści po prostu nie podają żadnych definicji swoich usług RESTful.

1.2 Jak przetestować Sieć usługa

Aby upewnić się, że usługa internetowa działa, utwórz i uruchom na niej test funkcjonalny.

Te testy wysyłają żądanie do serwera i weryfikują jego odpowiedź. W ReadyAPI użytkownik może stworzyć test funkcjonalny w SoapUI. Chociaż nazwa nazywa się „SoapUI”, użytkownicy mogą tworzyć testy dla usług SOAP i REST. Użytkownicy mogą łatwo symulować żądania i dostosowywać swoje parametry w specjalnym edytorze:

Aby zweryfikować dane odpowiedzi i kod odpowiedzi, dodaj potwierdzenie do żądania testowego:

Najłatwiejszym sposobem ustalenia, czy serwer działa poprawnie, jest sprawdzenie kodu odpowiedzi. 200 OK zwykle oznacza, że ​​serwer pomyślnie przetworzył żądanie.

W rzeczywistości klienci zazwyczaj wysyłają serię żądań do serwera. Na przykład w przypadku sklepu internetowego pierwsze żądanie może służyć do logowania, a kolejne żądania służą do zakupu określonych produktów. To rzeczywiste zachowanie można zasymulować w SoapUI, organizując żądania i inne kroki testowe w przypadki testowe:

Wiele przypadków testowych tworzy zestaw testów, który z kolei należy do projektu testowego. W następnej sekcji utworzymy projekt testowy i dodamy do niego automatyczny test funkcjonalny.

dwa , utwórz test funkcjonalny

Definicja WSDL tej usługi jest wymagana do testowania usługi SOAP w ReadyAPI. Ta definicja opisuje format operacji, żądania i odpowiedzi usługi. ReadyAPI wykorzystuje te informacje do symulacji żądania.

Można również zdefiniować usługi REST. Najczęściej używanymi formatami definicji są OpenAPI (wcześniej znany jako Swagger), WADL i inne formaty. Użytkownicy mogą załadować te definicje do ReadyAPI i tworzyć przypadki testowe na podstawie informacji zawartych w tych definicjach. Ale ogólnie usługi REST mogą w ogóle nie być zdefiniowane. Użytkownicy mogą tworzyć testy dla takich usług w ReadyAPI, logując żądanie adresu URL usługi (jest to nazywane wykrywaniem API). ReadyAPI otrzyma informacje o parametrach żądania i odpowiedzi na podstawie śledzonej usługi. Jednak te dane „obserwacji” nie są tak dokładne, jak informacje zawarte w definicji, dlatego zalecamy stosowanie definicji tam, gdzie to możliwe.

Tutaj utworzymy test na przykładzie usługi internetowej sklepu zoologicznego. To jest usługa REST, a jej definicję można znaleźć tutaj:

http://petstore.swagger.io/v2/swagger.json

Ta definicja ma format OpenAPI 2.0 (Swagger). Tutaj użytkownik nie musi teraz pobierać definicji, ReadyAPI zrobi to po utworzeniu testu funkcjonalnego. Konkretny proces tworzenia jest następujący:

1. Przejdź do strony startowej SoapUI i kliknij Utwórz test na podstawie definicji interfejsu API ：

2. Określ adres URL definicji usługi WWW w kolejnym kreatorze. W naszym przypadku tak jest http://petstore.swagger.io/v2/swagger.json ,następnie kliknij Kolejny przejdź do następnego kroku

3. Wybierz, czy chcesz utworzyć nowy projekt dla dodanej definicji, czy dodać go do istniejącego projektu. Kliknij Kolejny 'kontynuować.

Uwaga: ten krok zostanie pominięty, jeśli Kreator projektu nie jest otwarty w obszarze roboczym. W takim przypadku ReadyAPI utworzy nowy projekt i doda do niego nowe testy.

4. Ten krok umożliwia użytkownikowi wybranie twierdzeń, które mają zostać dodane do testu. ReadyAPI dodaje wybrane potwierdzenia do nowego żądania testu.

Asercje sprawdzają, czy interfejs API użytkownika działa zgodnie z oczekiwaniami, i opiszemy je bardziej szczegółowo w dalszej części tego samouczka. Ale teraz wyczyść zaznaczoną opcję i kliknij „Dalej”.

5. Wybierz, czy chcesz mieć przypadek testowy dla wszystkich operacji zdefiniowanych dla usługi sieci Web, czy też chcesz użyć wielu przypadków testowych (po jednym dla każdej operacji). Używamy drugiej opcji i klikamy „Zakończ”, aby utworzyć test.

6. ReadyAPI utworzy projekt testowy i doda do niego przypadki testowe.

Następnie wyświetli okno dialogowe, w którym użytkownik może wybrać „Uruchom utworzony test” lub „Dodaj do niego źródło danych”. W tym artykule nie będziemy używać tych opcji do zamykania tego okna dialogowego:

3 Test eksploracyjny Projekt projekt

Po wykonaniu drugiego kroku użytkownik może zobaczyć utworzoną pozycję testową w panelu Nawigator po lewej stronie:

Projekt ma wiele przypadków testowych, z których wszystkie są zgrupowane w zestawie testów, który z kolei należy do projektu. W naszym przypadku jest tylko jeden krok testowy żądania dla każdego przypadku testowego. W rzeczywistości przypadek testowy użytkownika zwykle składa się z kilku kroków:

W następnym kroku tego samouczka wyjaśnimy, jak dodać żądanie do przypadku testowego.

Aby przeglądać usługę, przejdź do strony „Projekty” w ReadyAPI. W panelu nawigacyjnym po lewej stronie użytkownik zobaczy strukturę drzewa zasobu usługi i żądanie:

Najwyższy węzeł odpowiada usłudze sieci Web, a jego węzły podrzędne odpowiadają zasobom, a węzły zasobów mają z kolei węzły podrzędne. Te węzły potomne odpowiadają żądaniom zdefiniowanym przez zasoby w specyfikacji usługi sieci Web.

Skorzystaj z edytora po prawej stronie, aby wyświetlić parametry wybranej usługi, zasobu lub zgłoszenia.

Niektóre zasoby definiują wiele żądań, które zwykle mają różne metody HTTP, a inne mają tylko jedno żądanie. Żądanie, które użytkownik widzi w strukturze drzewa projektów, działa jak żądanie szablonu. Na przykład użytkownik może tutaj ustawić różne parametry w każdym żądaniu, a następnie użyć tych żądań jako podstawy do etapu testowania żądań w SoapUI.

W projekcie użytkownicy mogą tworzyć jak najwięcej szablonów dla żądania.

Użytkownik może również uruchomić żądanie z edytora żądań, aby sprawdzić, czy żądanie działa, ale należy pamiętać, że będzie to pojedyncze uruchomienie żądania. Aby zasymulować rzeczywisty scenariusz, użytkownicy muszą uruchamiać przypadki testowe z wieloma żądaniami.