SoapUI - Szybki przewodnik

SOAP to skrót od Simple Object Access Protocol. Jest zdefiniowany przez konsorcjum World Wide Web Consortium (W3C) pod adresemhttps://www.w3.org/TR/2000/NOTE-SOAP-20000508 w następujący sposób -

SOAP to lekki protokół do wymiany informacji w zdecentralizowanym, rozproszonym środowisku. Jest to protokół oparty na języku XML, który składa się z trzech części: koperty definiującej strukturę opisującą zawartość wiadomości i sposób jej przetwarzania; zestaw reguł kodowania służących do wyrażania wystąpień typów danych zdefiniowanych w aplikacji; oraz konwencję reprezentowania zdalnych wywołań procedur i odpowiedzi.

MYDŁO - ważne funkcje

Poniżej przedstawiono kilka ważnych funkcji protokołu SOAP.

• Jest to protokół komunikacyjny przeznaczony do komunikacji przez Internet.

• Może rozszerzyć protokół HTTP na potrzeby przesyłania wiadomości XML.

• Zapewnia transport danych dla usług internetowych.

• Może wymienić kompletne dokumenty lub wezwać zdalną procedurę.

• Może służyć do nadawania wiadomości.

• Jest niezależny od platformy i języka.

• Jest to sposób definiowania w formacie XML, jakie informacje są wysyłane iw jaki sposób.

• Umożliwia aplikacjom klienckim łatwe łączenie się z usługami zdalnymi i wywoływanie metod zdalnych.

Chociaż protokół SOAP może być używany w różnych systemach przesyłania wiadomości i może być dostarczany za pośrednictwem różnych protokołów transportowych, początkowo SOAP koncentruje się na zdalnych wywołaniach procedur przesyłanych za pośrednictwem protokołu HTTP. Inne struktury, takie jak CORBA, DCOM i Java RMI, zapewniają podobną funkcjonalność do SOAP, ale komunikaty SOAP są w całości napisane w języku XML i dlatego są wyjątkowo niezależne od platformy i języka.

Wiadomość SOAP to zwykły dokument XML zawierający następujące elementy -

• Envelope- określa początek i koniec wiadomości. Jest to element obowiązkowy.

• Header- zawiera wszelkie opcjonalne atrybuty wiadomości wykorzystywane do przetwarzania wiadomości w punkcie pośrednim lub w ostatecznym punkcie końcowym. Jest to element opcjonalny.

• Body- zawiera dane XML składające się na wysyłaną wiadomość. Jest to element obowiązkowy.

• Fault - Opcjonalny element Fault, który zawiera informacje o błędach, które wystąpiły podczas przetwarzania wiadomości.

Wszystkie te elementy są zadeklarowane w domyślnej przestrzeni nazw dla koperty SOAP -

https://www.w3.org/2001/12/soap-envelope

Domyślna przestrzeń nazw dla kodowania SOAP i typów danych to -

https://www.w3.org/2001/12/soap-encoding

Note- Wszystkie te specyfikacje mogą ulec zmianie. Dlatego aktualizuj się zgodnie z najnowszymi specyfikacjami dostępnymi na stronie internetowej W3.

SOAP - struktura wiadomości

Poniższy blok przedstawia ogólną strukturę wiadomości SOAP -

<?xml version = "1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">  
   <SOAP-ENV:Header> 
      ... 
      ... 
   </SOAP-ENV:Header>  
   <SOAP-ENV:Body> 
      ... 
      ... 
      <SOAP-ENV:Fault> 
         ... 
         ... 
      </SOAP-ENV:Fault>  
   </SOAP-ENV:Body>  
</SOAP_ENV:Envelope>

REST to skrót od Representational State Transfer. Można go zdefiniować jako architektoniczny styl projektowania oprogramowania. REST nie jest specyfikacją ani standardem W3C. Dlatego łatwiej jest pracować z usługami RESTful. Nie wymaga żadnej struktury specyfikacji oprogramowania pośredniego.

REST - Ważne funkcje

Poniżej przedstawiono kilka ważnych funkcji REST.

• Opiera się na bezstanowym protokole komunikacyjnym klient-serwer, który można buforować - praktycznie we wszystkich przypadkach używany jest protokół HTTP.

• Jest to lekka alternatywa dla WebService i RPC (Remote Procedure Call), jak SOAP-WSDL.

• Reprezentuje wszystko w unikalnym identyfikatorze lub URI.

• Wykorzystuje standardowe metody HTTP, takie jak GET, POST, PUT, DELETE.

• Łączy źródła razem.

• Zasoby REST mogą mieć wiele reprezentacji.

• Wszelkie nazwane informacje są traktowane jako zasób. Na przykład: obraz, osoba, dokument, wszystko to może być traktowane jako przykład zasobu i przedstawiane jako unikalny identyfikator lub URI.

• Sama sieć World Wide Web, oparta na protokole HTTP, może być postrzegana jako architektura oparta na REST.

Usługi REST są niezależne od platformy i języka. Ponieważ jest oparty na standardach HTTP, może z łatwością działać w obecności zapór ogniowych. Podobnie jak WebServices, REST nie oferuje żadnych wbudowanych zabezpieczeń, zarządzania sesjami ani gwarancji QoS, ale można je dodać, budując na podstawie HTTP. Do szyfrowania można użyć REST oprócz HTTPS.

SoapUI to narzędzie, które może być używane zarówno do testów funkcjonalnych, jak i niefunkcjonalnych. Nie ogranicza się do usług sieciowych, chociaż jest de facto narzędziem używanym do testowania usług sieciowych.

SoapUI - ważne funkcje

Oto kilka ważnych funkcji SoapUI.

• Jest w stanie pełnić rolę zarówno klienta, jak i usługi.

• Pozwala użytkownikom na szybkie i efektywne tworzenie testów funkcjonalnych i niefunkcjonalnych przy użyciu jednego środowiska.

• Jest licencjonowany na warunkach licencji GNU Leaser General Public License (LGPL).

• Jest realizowany wyłącznie przy użyciu platformy JAVA.

• Obsługuje Windows, Mac, wiele dialektów Linuksa.

• Umożliwia testerom wykonywanie zautomatyzowanych testów funkcjonalnych, regresji, zgodności i testów obciążenia w różnych interfejsach API sieci Web.

• Obsługuje wszystkie standardowe protokoły i technologie do testowania wszystkich rodzajów API.

SoapUI może służyć do testowania pełnych testów RESTful API i SOAP Web Service. Obsługuje testy funkcjonalne, testy wydajności, testy współdziałania, testy regresji, testy obciążenia i wiele innych.

Jest przyjazny dla użytkownika, a także łatwo przekształcić test funkcjonalny w testy niefunkcjonalne, takie jak testy obciążeniowe, obciążeniowe.

SoapUI jest bogate w pięć następujących aspektów -

• Testy funkcjonalności
• Testowanie bezpieczeństwa
• Testowanie obciążenia
• Protokoły i technologie
• Integracja z innymi narzędziami

Dowiedzmy się więcej o każdej z tych możliwości.

Testy funkcjonalności

• SoapUI umożliwia testerom pisanie testów funkcjonalnych API w SoapUI.

• SoapUI obsługuje funkcję Drag-Drop, która przyspiesza tworzenie skryptu.

• SoapUI obsługuje debugowanie testów i umożliwia testerom tworzenie testów opartych na danych.

• SoapUI obsługuje wiele środowisk, ułatwiając przełączanie między środowiskami QA, Dev i Prod.

• SoapUI umożliwia zaawansowane tworzenie skryptów (tester może opracować własny kod w zależności od scenariuszy).

Testowanie bezpieczeństwa

• SoapUI wykonuje pełny zestaw skanowania luk w zabezpieczeniach.

• SoapUI zapobiega iniekcji SQL w celu zabezpieczenia baz danych.

• SoapUI skanuje w poszukiwaniu przepełnień stosu spowodowanych dużymi rozmiarami dokumentów.

• SoapUI skanuje w poszukiwaniu skryptów między lokacjami, które występują, gdy parametry usługi są ujawniane w komunikatach.

• SoapUI wykonuje skanowanie fuzzingowe i skanowanie granic, aby uniknąć błędnego działania usług.

Testowanie obciążenia

• SoapUI rozdziela testy obciążenia na n liczbę agentów LoadUI.

• SoapUI z łatwością symuluje duże wolumeny i testy obciążenia w świecie rzeczywistym.

• SoapUI umożliwia zaawansowane raportowanie niestandardowe w celu przechwytywania parametrów wydajności.

• SoapUI umożliwia kompleksowe monitorowanie wydajności systemu.

Protokoły i technologie

SoapUI obsługuje szeroką gamę protokołów -

• SOAP - Simple Object Access Protocol
• WSDL - język definicji usługi sieci Web
• REST - Reprezentacyjny transfer państwa
• HTTP - Hyper Text Transmission Protocol
• HTTPS - zabezpieczony protokół transmisji hipertekstu
• AMF - Action Message Format
• JDBC - łączność z bazą danych Java
• JMS - Java Messaging Service

Integracja z innymi narzędziami

• Projekt Apache Maven
• HUDSON
• JUnit
• Apache - Ant i nie tylko….

SoapUI to bezpłatne narzędzie w wersji open source z podstawowymi funkcjami testowania, podczas gdy SoapUI NG Pro to skomercjalizowane narzędzie posiadające zaawansowane funkcje raportowania, funkcje oparte na danych i wiele więcej.

Porównanie

Poniższa tabela porównuje i kontrastuje różne funkcje SoapUI i SoapUI NG Pro.

funkcje	SoapUI	SoapUI NG Pro
Supported Technologies
MYDŁO	tak	tak
WSDL / WADL	tak	tak
ODPOCZYNEK	tak	tak
JMS	tak	tak
AMF	tak	tak
JDBC	tak	tak
HTTP	tak	tak
General Features
Samodzielna aplikacja	tak	tak
Obsługa wielu środowisk	Nie	tak
Licencja sieciowa	Nie	tak
Pokrycie WSDL	Nie	tak
Zakres żądań / odpowiedzi	Nie	tak
Potwierdzenie wiadomości	tak	tak
Refaktoryzacja testów	Nie	tak
Przeprowadzanie wielu testów	tak	tak
Test oparty na źródle danych	Nie	tak
Biblioteki skryptów	Nie	tak
Raportowanie jednostek	Nie	tak
Ręczne kroki testowe	tak	tak
Reporting
Junit Reports	Nie	tak
Raport Eksport danych	Nie	tak
Raport HTML WSDL	tak	tak
Pokrycie zestawu testów	Nie	tak
Pokrycie przypadków testowych	Nie	tak
Pokrycie twierdzeń	Nie	tak
Pokrycie nagrania wiadomości	Nie	tak

SoapUI to narzędzie wieloplatformowe. Obsługuje systemy operacyjne Windows, Linux i Mac.

Wymagania wstępne

• Processor - Procesor 32- lub 64-bitowy 1 GHz lub szybszy.

• RAM - 512 MB pamięci RAM.

• Hard Disk Space - Minimum 200 MB wolnego miejsca na dysku do instalacji.

• Operating System Version - Windows XP lub nowszy, MAC OS 10.4 lub nowszy.

• JAVA - JAVA 6 lub nowsza.

Proces pobierania

Step 1- Przejdź do www.soapui.org i kliknij Pobierz SoapUI.

Step 2- Kliknij „Pobierz”, aby pobrać SoapUI Open Source. Rozpocznie się pobieranie pliku 112MB .exe w systemie. Poczekaj, aż proces pobierania się zakończy.

Proces instalacji

Step 1 - Po pobraniu uruchom plik .exe jako „Uruchom jako administrator”.

System Windows rozpocznie proces konfiguracji, jak pokazano na poniższym zrzucie ekranu.

Step 2 - Po skonfigurowaniu w oknie procesu zostanie wyświetlony następujący ekran, kliknij przycisk Dalej.

Step 3 - Zaakceptuj umowę licencyjną i kliknij Dalej.

Step 4- Wybierz katalog instalacyjny lub zachowaj go jako domyślną ścieżkę wybraną przez system. Kliknij Następny.

Step 5- Wybierz składniki, które chcesz zainstalować. Kliknij Następny.

Step 6 - Zaakceptuj Umowę Licencyjną dla HermesJMS i kliknij Dalej.

Step 7 - Wybierz katalog docelowy do zapisania samouczków i kliknij Dalej.

Step 8 - Wybierz lokalizację folderu menu Start lub pozostaw domyślną lokalizację bez zmian i kliknij „Dalej”.

Step 9 - Zaznacz pole wyboru „utwórz ikonę na pulpicie” i kliknij „Dalej”.

Teraz rozpocznie się instalacja. To zajmie kilka minut.

Step 10 - Po zakończeniu instalacji kliknij Zakończ w następującym kreatorze.

Po kliknięciu Zakończ uruchamia się SoapUI.

• Pasek menu
• Pasek narzędzi
• Pasek nawigacji projektu
• Właściwości obszaru roboczego
• Panel dziennika

Proces konfiguracji

Pierwszym krokiem jest utworzenie obszaru roboczego, który może zawierać wiele projektów.

Step 1 - Idź do Plik → Nowy obszar roboczy.

Step 2 - Dodaj nazwę obszaru roboczego i kliknij OK.

Step 3 - Teraz wybierz ścieżkę, w której zostanie zapisany plik XML obszaru roboczego.

Step 4 - Wybierz ścieżkę i kliknij Zapisz.

Obszar roboczy jest tworzony, jak pokazano na poniższym zrzucie ekranu. Wyświetlane są również właściwości obszaru roboczego.

WSDL oznacza język opisu usług sieciowych. Jest to standardowy format opisu usługi internetowej. WSDL został opracowany wspólnie przez Microsoft i IBM. WSDL jest wymawiane jako „wiz-dull” i zapisywane jako „WSD-L”.

WSDL ─ Krótka historia

WSDL 1.1 został przedstawiony jako notatka W3C przez Ariba, IBM i Microsoft za opisanie usług związanych z działaniem W3C XML dotyczącym protokołów XML w marcu 2001 r.

WSDL 1.1 nie został zatwierdzony przez World Wide Web Consortium (W3C), jednak właśnie opublikował projekt wersji 2.0, który będzie rekomendacją (oficjalnym standardem), a zatem został zatwierdzony przez W3C.

WSDL ─ Warto zwrócić uwagę

WSDL to oparty na XML protokół do wymiany informacji w zdecentralizowanym i rozproszonym środowisku. Niektóre z innych funkcji WSDL są następujące -

• Definicje WSDL opisują, jak uzyskać dostęp do usługi WWW i jakie operacje ona wykona.

• Jest to język opisujący sposób łączenia się z usługami opartymi na języku XML.

• Stanowi integralną część Universal Description, Discovery and Integration (UDDI), światowego rejestru biznesowego opartego na języku XML.

• WSDL to język używany przez UDDI.

Wykorzystanie WSDL

WSDL jest często używany w połączeniu ze schematem SOAP i XML w celu świadczenia usług WWW przez Internet. Program klienta łączący się z usługą WWW może odczytać WSDL, aby określić, jakie funkcje są dostępne na serwerze. Wszelkie używane specjalne typy danych są osadzane w pliku WSDL w postaci schematu XML. Klient może następnie użyć protokołu SOAP do rzeczywistego wywołania jednej z funkcji wymienionych w WSDL.

Zrozumienie WSDL

WSDL dzieli usługi sieciowe na trzy określone, możliwe do zidentyfikowania elementy, które po zdefiniowaniu można łączyć lub ponownie wykorzystywać.

Trzy główne elementy WSDL, które można zdefiniować oddzielnie, to -

• Types
• Operations
• Binding

Dokument WSDL ma różne elementy, ale są one zawarte w tych trzech głównych elementach, które można opracować jako oddzielne dokumenty, a następnie można je łączyć lub ponownie wykorzystywać w celu utworzenia kompletnych plików WSDL.

W tym samouczku śledzimy CurrencyConverter WSDL: http://www.webservicex.net

Format i elementy

CurrencyConverter WSDL będzie wyglądać następująco -

WSDL ─ Typ portu

Element <portType> łączy wiele elementów komunikatu, tworząc pełną operację w jedną stronę lub w obie strony. Na przykład <portType> może łączyć jedno żądanie i jeden komunikat odpowiedzi w jedną operację żądania / odpowiedzi. Jest to najczęściej używane w usługach SOAP. PortType może definiować wiele operacji.

Przykład

• Element portType definiuje pojedynczą operację o nazwie ConversionRate.
• Operacja składa się z pojedynczego komunikatu wejściowego ConversionRateHttpPostIn.
• Operacja dla komunikatu wyjściowego to ConversionRateHttpPostOut.

Wzorce działania

WSDL obsługuje cztery podstawowe wzorce działania -

Jednokierunkowa

Usługa otrzymuje wiadomość. Dlatego operacja ma jeden element wejściowy. Gramatyka operacji jednokierunkowej to -

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Żądanie ─ Odpowiedź

Usługa odbiera wiadomość i wysyła odpowiedź. Dlatego operacja ma jeden element wejściowy, po którym następuje jeden element wyjściowy. Aby hermetyzować błędy, można również określić opcjonalny element błędu. Gramatyka operacji żądanie-odpowiedź to -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Poproś ─ Odpowiedź

Usługa wysyła wiadomość i otrzymuje odpowiedź. Dlatego operacja ma jeden element wyjściowy, po którym następuje jeden element wejściowy. Aby hermetyzować błędy, można również określić opcjonalny element błędu. Gramatyka dla operacji prośby o odpowiedź to -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Powiadomienia

Usługa wysyła wiadomość. Dlatego operacja ma jeden element wyjściowy. Poniżej znajduje się gramatyka operacji powiadamiania -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

WSDL ─ Wiązanie i usługi

Plik <binding>zawiera szczegółowe informacje o tym, jak operacja portType będzie faktycznie przesyłana przez kabel.

• Powiązania można udostępnić za pośrednictwem wielu transportów, w tym HTTP GET, HTTP POST lub SOAP.

• Powiązania zapewniają konkretne informacje o protokole używanym do przesyłania operacji typu portType.

• Powiązania dostarczają informacji o lokalizacji usługi.

• W przypadku protokołu SOAP powiązanie to <soap: binding>, a transport to komunikaty SOAP na wierzchu protokołu HTTP.

• Możesz określić wiele powiązań dla jednego typu portType.

Usługa

Plik <service>element definiuje porty obsługiwane przez usługę internetową. Dla każdego z obsługiwanych protokołów istnieje jeden element portu. Element usługi to zbiór portów.

Klienci usługi sieci Web mogą nauczyć się następujących elementów usługi -

• Gdzie uzyskać dostęp do usługi,
• Przez który port można uzyskać dostęp do usługi internetowej i
• Jak definiowane są komunikaty komunikacyjne.

Element usługowy zawiera element dokumentacji zapewniający czytelną dla człowieka dokumentację.

<wsdl:service name = "CurrencyConvertor">
   <wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
      <soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
      <soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port> 
</wsdl:service>

Projekt SoapUI jest centralnym punktem wszystkich testów SoapUI. Po utworzeniu projektu użytkownik może tworzyć i uruchamiać testy funkcjonalne, testy ładowania, tworzyć usługi pozorowane i wiele więcej.

W tym rozdziale omówimy dwie rzeczy - Jak -

• Utwórz projekt SOAP
• Dodaj WSDL

Utwórz projekt SOAP

Step 1 - W nawigatorze po lewej stronie ekranu kliknij prawym przyciskiem myszy „Projekt” i wybierz „Nowy projekt SOAP”.

Lub przejdź do File i wybierz New Soap Project.

Po dokonaniu wyboru otwiera się nowe wyskakujące okienko - Nowy projekt mydła.

Step 2 - Project Name: Wpisz nazwę projektu - jest to pole wejściowe użytkownika. Initial WSDL: To nie jest obowiązkowe. To zależy od użytkownika. Użytkownik może dostarczyć WSDL lub dodać po utworzeniu projektu.

W takim przypadku tworzymy projekt i później dodajemy WSDL.

Step 3- Kliknij OK. Utworzy nowy projekt i będzie widoczny w lewym panelu nawigacyjnym.

Dodaj WSDL

Projekty SOAP są oparte na WSDL. Nie trzeba zaczynać od zaimportowania WSDL, ale ułatwia to testowanie, ponieważ WSDL zawiera wszystkie informacje wymagane do testowania usługi internetowej, takie jak informacje o żądaniach i odpowiedziach, ich zawartość i wiele więcej, co upraszcza testowanie SoapUI.

Step 1 - Aby dodać WSDL, kliknij prawym przyciskiem myszy nazwę projektu (SOAP - przykład) i wybierz Dodaj WSDL.

Po wybraniu zostanie wyświetlony kreator WSDL.

Step 2 - WSDL Location: Wprowadź WSDL jako http://www.webservicex.com lub przeglądaj go na komputerze.

Step 3- Po wprowadzeniu WSDL 3 pola wyboru - Utwórz żądania, Utwórz TestSuite, Utwórz MockServices zostaną włączone. W zależności od wymagań użytkownik może zaznaczyć jedno lub wiele pól wyboru.

Domyślnie pole wyboru Utwórz żądania jest zaznaczone.

Step 4- Kliknij OK. WSDL został pomyślnie dodany do projektu. Można to sprawdzić, obserwując lewy panel nawigacyjny. Wewnątrz projektu jest wiele operacji, a żądania są dodawane zgodnie z WSDL.

Widok szczegółów

Aby uzyskać więcej informacji o projekcie, kliknij dwukrotnie nazwę projektu, otworzy się nowe okno z różnymi szczegółami.

Na karcie Przegląd dostępne są różne informacje, takie jak -

• File Path - Wyświetla lokalizację zapisanego projektu xml.

• Interface Summary - Nazwa interfejsu i skojarzony z nim WSDL.

• Test Summary - Wyświetla zestawy testów, przypadki testowe, kroki testowe, potwierdzenia dodane do projektu.

Użytkownik może dwukrotnie kliknąć nazwę interfejsu, aby uzyskać szczegółowe informacje o interfejsie. Otworzy się nowe okno i wyświetli informacje związane z WSDL. Są one bardzo przydatne do przeglądania i testowania WSDL.

Na karcie Przegląd zawiera definicje WSDL, części definicji i szczegóły operacji.

Podobnie Service Endpoints wyświetla szczegóły punktów końcowych.

Na karcie Zawartość WSDL wszystkie szczegóły WSDL w formacie XML / schematu są podane, jak pokazano na poniższym zrzucie ekranu.

TestSuiteto zbiór przypadków testowych, których można używać do grupowania testów funkcjonalnych w jednostki logiczne. W ramach projektu SoapUI można utworzyć dowolną liczbę pakietów TestSuites w celu obsługi scenariuszy testowania masowego.

Stworzenie TestSuite

Step 1 - W projekcie kliknij prawym przyciskiem myszy interfejs (obok nazwy projektu), a następnie kliknij „Generuj TestSuite”.

Tutaj SOAP - Example to nazwa projektu, podczas gdy CurrencyConvertorSoap i CurrencyConvertorSoap12 są interfejsami.

Step 2- Otwiera się nowy kreator. Wybierz opcje w oparciu o wymagania.

Step 3 - Po dokonaniu wyboru kliknij OK.

Step 4- Zaznacz pole wyboru Generate LoadTest. Spowoduje to wygenerowanie LoadTest dla każdego TestCase utworzonego w tym TestSuite.

Step 5 - Wprowadź nazwę TestSuite w nowym kreatorze, a następnie kliknij OK.

Utworzony TestSuite wyświetla się w panelu nawigacyjnym, jak pokazano na poniższym zrzucie ekranu.

Step 6- Kliknij dwukrotnie nazwę TestSuite, a na prawym panelu otworzy się okno TestSuite. Ponieważ nie dodano żadnych przypadków testowych, pole jest puste.

Właściwości TestSuite można zobaczyć u dołu panelu nawigacyjnego. Nowe właściwości niestandardowe można dodać na poziomie TestSuite.

TestCase to zbiór TestSteps zebranych w celu przetestowania określonego aspektu usług internetowych. Użytkownik może dodać n liczbę przypadków TestCases do zestawu TestSuite, a nawet modularyzować je, aby wywoływały się nawzajem w przypadku złożonych scenariuszy testowych.

Utworzenie TestCase

Step 1- W ramach TestSuite użytkownik może dodać wiele przypadków testowych. Kliknij prawym przyciskiem myszy pakiet testowy i wybierz „Nowy przypadek testowy”.

Step 2 - Wprowadź nazwę przypadku TestCase i kliknij OK.

Utworzona TestCase ma na razie zero kroków testowych. TestCase jest dodawany z zerową liczbą TestSteps dla wszystkich dostępnych testów. Po dodaniu TestSteps liczby w nawiasach zmienią się automatycznie. Funkcjonalny TestStep powinien przejść do „Test Steps”, a Performance TestStep powinien przejść do „Load Test”, a Security TestStep powinien przejść do „Security Tests”.

Step 3- Kliknij dwukrotnie nazwę przypadku TestCase, a na panelu po prawej stronie otworzy się okno TestCase. Ponieważ nie dodano żadnych TestSteps, jest on pusty, jak widać na poniższym zrzucie ekranu.

TestSteps to „bloki konstrukcyjne” testów funkcjonalnych w SoapUI. Są one dodawane do TestCase i używane do kontrolowania przebiegu wykonywania i sprawdzania funkcjonalności testowanych usług internetowych.

Wstawianie TestStep

Step 1- Kliknij prawym przyciskiem myszy TestSteps. Dodaj krok i wybierz odpowiedni TestStep z listy. Na przykład, jeśli użytkownik musi przetestować usługę REST WebService, wybierze żądanie testu REST.

Step 2 - Dodaj TestStep, aby zweryfikować zaimportowane żądanie SOAP, wybierając TestSteps → Dodaj krok → Żądanie SOAP.

Step 3 - Wprowadź nazwę kroku testowego i kliknij OK w kreatorze.

Po kliknięciu „OK”, pojawia się okno dialogowe, w którym można wybrać operację do wywołania. Wyświetlane są wszystkie operacje, a użytkownicy mogą wybrać operację, którą chcieliby wywołać.

Zostaną wyświetlone dwie operacje. Obie operacje są takie same, z wyjątkiem używanej wersji protokołu SOAP.CurrencyConvertorSoap używa protokołu SOAP w wersji 1.1, podczas gdy CurrencyConvertorSoap12 używa protokołu SOAP w wersji 1.2.

Step 4 - Wybierz pierwszy - CurrencyConvertorSoap i kliknij OK.

Podczas dodawania TestCase można dodać różne standardowe asercje. Asercje są również nazywane punktami kontrolnymi / punktami weryfikacji żądania / odpowiedzi SOAP.

Step 5 - Stwórzmy TestCase z domyślną opcją, co oznacza utworzenie TestStep BEZ któregokolwiek z poniższych punktów weryfikacji -

• Sprawdza, czy komunikat odpowiedzi to SOAP, po wykonaniu testu.
• Sprawdza, czy schemat odpowiedzi jest prawidłowy.
• Sprawdza, czy odpowiedź SOAP zawiera FAULT.

Step 6 - Po kliknięciu OK, pojawi się następujący zrzut ekranu XML żądania.

Liczba kroków testu jest teraz zwiększana do jednego w miarę dodawania funkcjonalnego TestStep. Podobnie, po dodaniu TestSteps obciążenia i bezpieczeństwa, odpowiednia liczba automatycznie rośnie w zależności od liczby dodanych kroków.

Poproś o konfigurację

Tutaj dokonamy przewalutowania waluty z INR na USD.

• FromCurrency - INR
• ToCurrency - USD

Następnie wprowadź te dane wejściowe w miejscu znaku zapytania, który zostanie wysłany jako żądanie XML. Po umieszczeniu tych wartości w odpowiednich tagach XML, kliknij przycisk „Prześlij żądanie”, aby sprawdzić odpowiedź.

Odpowiedź

Po przesłaniu żądania żądanie usługi sieci Web jest przetwarzane przez serwer sieciowy i odsyła odpowiedź, jak pokazano na poniższym zrzucie ekranu.

Czytając odpowiedź można wywnioskować, że 1 jednostka INR = 0,0147 jednostki USD.

Żądanie HTTP

Komunikaty SOAP są przesyłane przez protokół HTTP. Aby wyświetlić żądanie HTTP, kliknij RAW w oknie żądania SoapUI (lewa strona).

Żądanie jest wysyłane na serwer WWW. W związku z tym używana jest metoda POST Http.

Żądanie SOAP jest przesyłane w treści komunikatu http, co pokazano poniżej.

POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1 
Accept-Encoding: gzip,deflate 
Content-Type: text/xml;charset = UTF-8 
SOAPAction: "http://www.webserviceX.NET/ConversionRate" 
Content-Length: 353 
Host: www.webservicex.com 
Connection: Keep-Alive 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Odpowiedź HTTP

Kliknij kartę „RAW” w oknie odpowiedzi SOAP-UI, aby dowiedzieć się, w jaki sposób odpowiedź jest wysyłana przez HTTP.

Po przetworzeniu żądania wyświetlany jest kod odpowiedzi http (200), co oznacza, że ​​się powiodło. Serwer internetowy pomyślnie go przetworzył.

Odpowiedź SOAP jest wysyłana z powrotem do klienta jako część treści komunikatu HTTP.

HTTP/1.1 200 OK 
Cache-Control: private, max-age = 0 
Content-Type: text/xml; charset = utf-8 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.0 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Sun, 22 Jan 2017 19:39:31 GMT 
Content-Length: 316

Następujące kody HTTP są używane do wysyłania odpowiedzi przez serwer WWW i są bardzo przydatne do debugowania.

Kod HTTP	Opis
1xx:	Informational - Oznacza to, że otrzymano żądanie i trwa proces.
2xx:	Success - Działanie zostało pomyślnie odebrane, zrozumiane i zaakceptowane.
3xx:	Redirection - Oznacza to, że należy podjąć dalsze działania w celu uzupełnienia wniosku.
4xx:	Client Error - Oznacza to, że żądanie zawiera złą składnię lub nie może zostać spełnione.
5xx:	Server Error - Serwer nie spełnił pozornie ważnego żądania.

Właściwości są centralnym aspektem bardziej zaawansowanych testów za pomocą SoapUI. Właściwości testów funkcjonalnych służą do parametryzacji wykonywania i funkcjonalności testów.

• Właściwości mogą służyć do przechowywania punktów końcowych usług, co ułatwia zmianę rzeczywistych punktów końcowych używanych podczas wykonywania testów.

• Właściwości mogą służyć do przechowywania poświadczeń uwierzytelniania, co ułatwia zarządzanie nimi w centralnym miejscu lub w pliku zewnętrznym.

• Właściwości mogą służyć do przesyłania i udostępniania identyfikatorów sesji podczas wykonywania testów, dzięki czemu wiele kroków testowych lub przypadków testowych może współużytkować te same sesje.

Definiowanie właściwości

Właściwości można definiować na wielu poziomach projektu.

• Właściwości, które są wspólne na poziomie projektu, można zdefiniować na poziomie projektu.

• Podobnie specyficzne właściwości TestSuite i TestCase można zdefiniować na odpowiednich poziomach.

• Właściwości specyficzne dla projektu są definiowane na karcie Właściwości niestandardowe.

Na przykład właściwość „ToCurrency” można zdefiniować na poziomie projektu, klikając symbol „+” i wprowadzając nazwę właściwości i wartość.

Dostęp do własności

Dostęp do właściwości można uzyskać z dowolnego miejsca w projekcie za pomocą rozszerzenia właściwości.

Struktura byłaby następująca -

• $ {# Project # PropertyName} - na poziomie projektu

• $ {# TestSuite # PropertyName} - na poziomie pakietu testów

• $ {# TestCase # PropertyName} - dla poziomu przypadku testowego

• $ {TestStepName # PropertyName} - dla poziomu kroku testowego

• $ {# MockService # PropertyName} - dla właściwości MockService

• $ {# Global # PropertyName} - dla właściwości globalnych, można je znaleźć w zakładce Plik → Preferencje → Właściwości globalne. Ta właściwość może być używana we wszystkich projektach

• $ {# System # PropertyName} - w przypadku właściwości systemu, można znaleźć w Pomocy → Właściwości systemu

• $ {# Env # PropertyName} - dla zmiennej środowiskowej

Tę samą strukturę można umieścić w żądaniu XML, aby uzyskać wartość określonego atrybutu w czasie wykonywania.

Właściwość można również traktować jako zmienną w programie komputerowym. Jeśli użytkownik chce zdefiniować coś, co może być użyte również w innym miejscu, właściwości są bardzo przydatne. Właściwości można również definiować dynamicznie, ale jest to zależne od skryptu Groovy.

Czasami istnieje potrzeba wyodrębnienia jakiejś wartości z komunikatu odpowiedzi i uwzględnienia jej w kolejnych żądaniach. W takim przypadku potrzebny jest nam mechanizm do pobrania określonej wartości i przeniesienia jej na inne elementy projektu. SoapUI obsługuje taką funkcjonalność poprzez TestStep Transferu Właściwości.

Dodawanie przeniesienia własności

Step 1 - Wybierz TestCase lub TestStep, kliknij prawym przyciskiem myszy → Dodaj kroki → Transfer właściwości.

Step 2 - Wprowadź nazwę TestStep i kliknij OK.

Step 3 - Dodano krok RateTransfer i otworzy się nowy kreator.

Step 4- Kliknij ikonę Dodaj nowe przeniesienie własności + w lewym górnym rogu okna przenoszenia własności. Zostanie wyświetlony monit o wprowadzenie nazwy przelewu. Wpisz Oceń i kliknij OK.

Przenoszenie własności

Po utworzeniu przelewu Source i Target panesnależy określić odpowiednie wyrażenia XPath, aby wyodrębnić i zamienić wartości właściwości. W rozwijanym polu obok Źródła wymienione są różne poziomy projektów SoapUI, które mogą być używane jako źródło przenoszenia własności. Domyślnie zostanie wyświetlony najbliższy TestStep.

W tym przypadku jest to plik Request – INR to USDTestStep. Lista rozwijana obok opcji Właściwość przedstawia właściwość źródłową używaną podczas przesyłania, która może być żądaniem, odpowiedzią lub punktem końcowym usługi.

Step 1- Wybierz odpowiedź i przejdź do Język ścieżki. Użytkownik może wybrać XPath, Xquery lub Jason, aby zdefiniować właściwość. W takim przypadku wybierz XPath.

Step 2 - Aby uzyskać deklarację źródła xml, kliknij ns i określ XPath.

Step 3- Określ cel, do którego ma zostać przesłana wartość wyodrębniona z powyższego wyrażenia XPath. W tym celu używane jest okienko docelowe w dolnej części okna przenoszenia właściwości.

Step 4 - Przenieś wyodrębnioną wartość ConversionRateResult z odpowiedzi kroku RequestINRtoUSD.

Target - Właściwości

Property - ConversionRate (dodano nową właściwość, początkowo nie ma żadnej wartości).

Step 5 - Po pomyślnym uruchomieniu przypadku testowego właściwość „ConversionRate” jest aktualizowana na podstawie odpowiedzi.

Poniżej znajduje się zrzut ekranu początkowo.

Poniżej znajduje się zrzut ekranu po udanym uruchomieniu.

Podobnie Target może być kolejnym żądaniem XML. Jeśli celem jest żądanie SOAP, musimy podać XPath, aby zidentyfikować atrybut docelowy.

Panel Logs przechowuje pełne informacje dotyczące transakcji między klientem a serwerem. Użytkownicy będą mogli zobaczyć różne zakładki okienka dziennika. W tym rozdziale omówimy najczęściej używane okienka dziennika podczas pracy z SoapUI.

Dziennik SoapUI

Dziennik SoapUI wyświetla informacje o odpowiedziach z serwera WWW. Te same informacje są przechowywane w pliku soapui.log w folderze zainstalowanym SOAP-UI w katalogu „bin”.

Dziennik HTTP

Dziennik HTTP wyświetla wszystkie transfery pakietów HTTP. Wszystkie informacje w „RAW” są wyświetlane w dzienniku HTTP.

Dziennik błędów

Dziennik błędów wyświetla wszystkie błędy napotkane podczas całej sesji projektu. Te same informacje są dostępne w pliku „soapui-errors.log” znajdującym się w katalogu „bin” w miejscu zainstalowania SoapUI.

Dziennik pamięci

Ta karta monitoruje zużycie pamięci i wyświetla je w formie wykresu, jak pokazano na poniższym zrzucie ekranu. Jest to naprawdę pomocne, gdy wykonywana jest operacja wymagająca dużej ilości pamięci.

Asercję można interpretować jako punkt kontrolny lub punkt weryfikacji. Po wysłaniu żądania do serwera WWW odbierana jest odpowiedź. Wymagane jest sprawdzenie poprawności odpowiedzi, która zawiera dane zgodnie z oczekiwaniami lub nie. Aby zweryfikować odpowiedź, SoapUI ma funkcję asercji.

Zwraca uwagę

• Asercje służą do sprawdzania poprawności komunikatu odebranego przez TestStep podczas wykonywania.

• Porównuje część wiadomości lub całą wiadomość z pewną oczekiwaną wartością.

• Do kroku testowego można dodać dowolną liczbę twierdzeń, z których każde weryfikuje inny aspekt i treść komunikatu odpowiedzi.

• Po wykonaniu TestStep wszystkie jego potwierdzenia są stosowane do odebranej odpowiedzi, a jeśli którekolwiek z nich nie powiedzie się, TestStep jest oznaczany jako nieudany w widoku TestCase.

• Niepowodzenie wpisu pojawia się w dzienniku wykonania testu.

Typ asercji

SoapUI obsługuje szeroki zakres twierdzeń w odpowiedzi.

Poniżej znajduje się lista twierdzeń obsługiwanych przez SoapUI.

Twierdzenie	Opis
Property Content
Zawiera	Sprawdza istnienie określonego ciągu. Obsługuje również wyrażenia regularne.
Nie zawiera	Sprawdza, czy podany ciąg nie istnieje. Obsługuje również wyrażenia regularne.
XPath Match	Używa wyrażenia XPath do wybierania węzła docelowego i jego wartości. Porównuje wynik wyrażenia XPath z oczekiwaną wartością.
XQuery Match	Używa wyrażenia Xquery, aby wybrać zawartość z właściwości docelowej. Porównuje wynik wyrażenia XQuery z oczekiwaną wartością.
Compliance, Status, Standards
HTTP DOwnload wszystkich zasobów	Pobiera wszystkie zasoby, do których odnosi się dokument HTML (obrazy, skrypty itp.) I sprawdza, czy są one dostępne. Ma zastosowanie do każdej właściwości zawierającej HTML.
Nieprawidłowe kody stanu HTTP	Sprawdza, czy docelowy TestStep odebrał wynik HTTP z kodem stanu, którego nie ma na liście zdefiniowanych kodów. Ma zastosowanie do każdego TestStep, który odbiera komunikaty HTTP.
To nie błąd SOAP	Sprawdza, czy ostatni otrzymany komunikat nie jest błędem protokołu SOAP. Dotyczy SOAP TestSteps.
Zgodność ze schematem	Sprawdza, czy ostatni otrzymany komunikat jest zgodny ze skojarzoną definicją schematu WSDL lub WADL. Dotyczy kroków testowych SOAP i REST. Adres URL definicji schematu obsługuje rozszerzenia właściwości (np. $ {# System # my.wsdl.endpoint} / services / PortType? Wsdl).
Błąd SOAP	Sprawdza, czy ostatni otrzymany komunikat jest błędem protokołu SOAP. Dotyczy SOAP TestSteps Żądanie SOAP - sprawdza, czy ostatnie odebrane żądanie jest poprawnym żądaniem SOAP. Dotyczy tylko etapów testu MockResponse.
Odpowiedź SOAP	Sprawdza, czy ostatnia otrzymana odpowiedź jest prawidłową odpowiedzią SOAP. Dotyczy tylko kroków SOAP TestRequest.
Prawidłowe kody stanu HTTP	Sprawdza, czy docelowy TestStep odebrał wynik HTTP z kodem stanu na liście zdefiniowanych kodów. Ma zastosowanie do każdego TestStep, który odbiera komunikaty HTTP.
Żądanie adresowania WS	Sprawdza, czy ostatnie odebrane żądanie zawiera prawidłowe nagłówki WS-Addressing. Dotyczy tylko MockResponse TestSteps.
Odpowiedź adresowania WS	Sprawdza, czy ostatnia otrzymana odpowiedź zawiera prawidłowe nagłówki WS-Addressing. Dotyczy tylko kroków SOAP TestRequest.
Stan bezpieczeństwa WS	Sprawdza, czy ostatni otrzymany komunikat zawierał prawidłowe nagłówki WS-Security. Dotyczy kroków testowych SOAP.
Script
Asercja skryptu	Umożliwia użytkownikom wykonanie skryptu niestandardowego w celu wykonania walidacji zdefiniowanych przez użytkownika. Dotyczy tylko TestSteps (tj. Nie ma zastosowania)
SLA
Umowa SLA dotycząca odpowiedzi	Sprawdza, czy czas odpowiedzi ostatniej otrzymanej odpowiedzi mieścił się w zdefiniowanym limicie. Dotyczy skryptów TestSteps i TestSteps, które wysyłają żądania i odbierają odpowiedzi.
JMS
Stan JMS	Sprawdza, czy żądanie JMS docelowego kroku TestStep zostało pomyślnie wykonane. Dotyczy żądania TestSteps z punktem końcowym JMS.
Limit czasu JMS	Sprawdza, czy instrukcja JMS docelowego kroku TestStep nie trwała dłużej niż określony czas trwania. Dotyczy żądania TestSteps z punktem końcowym JMS.
Security
Ujawnianie wrażliwych informacji	Sprawdza, czy komunikat odpowiedzi nie ujawnia poufnych informacji o systemie docelowym. Możemy użyć tej asercji dla REST, SOAP i HTTP TestSteps.
JDBC
Stan JDBC	Sprawdza, czy żądanie JDBC docelowego TestStep zostało pomyślnie wykonane. Dotyczy tylko JDBC TestSteps.
Limit czasu JDBC	Sprawdza, czy instrukcja JDBC docelowego TestStep nie trwała dłużej niż określony czas. Dotyczy tylko JDBC TestSteps.

W SoapUI użytkownicy napotykają wiele ogólnych typowych problemów, które można rozwiązać przy odrobinie czujności. Oto niektóre z tych najczęstszych problemów -

Issue- Przestrzeń nazw jest nieprawidłowo zdefiniowana. Użyj poprawnej przestrzeni nazw. Przestrzeń nazw powinna być adresem URL, pod którym znajduje się usługa internetowa.

Solution - Jeśli podczas tworzenia asercji skryptowej zostanie zgłoszony błąd, użyj „log.info”, aby wydrukować zawartość zmiennych.

Issue - Jeśli kod błędu zostanie odebrany jako XML odpowiedzi, może to być spowodowane nieprawidłowymi danymi wejściowymi.

Solution - Sprawdź dane wejściowe żądania XML.

Example - W przeliczniku walut, jeśli wartość wejściowa „FromCurrency” to „123”, która nie istnieje, wyjście generuje kod błędu jako „SOAP-Client”, co oznacza, że ​​problem dotyczy parametru przekazywanego z Strona klienta.

Żądanie

Odpowiedź

Issue - Brak dopasowania w bieżącej odpowiedzi podczas korzystania z XPath lub XQuery.

Solution -

• Użyj poprawnej składni podczas definiowania XPath lub XQuery.
• Sprawdź, czy podczas deklarowania przestrzeni nazw używany jest dwukropek, a nie kropka.
• Upewnij się, że XPath i XQuery są poprawne.

Testowanie wydajności jest jednym z najważniejszych punktów kontrolnych podczas testowania usług internetowych. Testowanie wydajnościowe definiuje się jako sztuczne tworzenie lub symulowanie obciążenia i mierzenie sposobu, w jaki środowisko je obsługuje.

Oznacza to, że nie musi tak być, jak system zachowuje się przy dużym obciążeniu, może to być również sposób, w jaki działa przy obciążeniu podstawowym lub oczekiwanym. Nie musi nawet być ustrukturyzowany, zautomatyzowany ani stworzony w TestWare, takim jak SoapUI; zwykłe ciągłe odświeżanie przeglądarki internetowej i bardzo szybkie jest również testem obciążenia.

Rodzaje testów wydajności

Poniżej przedstawiono rodzaje testów wydajności -

• Baseline Testing - Sprawdza, jak system działa przy oczekiwanym lub normalnym obciążeniu i tworzy punkt odniesienia, z którym można porównać inne typy testów.

• Load Testing- Obejmuje zwiększenie obciążenia i zobaczyć, jak system zachowuje się przy wyższym obciążeniu. Podczas testów obciążenia użytkownik może monitorować czasy odpowiedzi, przepustowość, stan serwera i wiele więcej. Celem testów obciążenia nie jest uszkodzenie środowiska docelowego.

• Soak Testing - Celem testowania jest upewnienie się, że przez dłuższy czas nie pojawi się żadne niepożądane zachowanie.

• Scalability Testing- Testowanie skalowalności jest bardzo podobne do testowania obciążenia, jednak zamiast zwiększać liczbę żądań, zwiększa rozmiar lub złożoność wysyłanych żądań. Na przykład wysyłanie dużych żądań, dużych załączników lub głęboko zagnieżdżonych żądań.

Kluczowe aspekty usług internetowych

Dwa aspekty wyróżniają się wyjątkowymi cechami wydajności usługi sieci Web.

Pierwszy aspekt

Po stronie serwera trwa przetwarzanie XML / JSON, zarówno parsowanie XML / JSON, jak i serializacja . To, co często zawodzi jako pierwsze, to przetwarzanie danych. Przyczyny niepowodzenia mogą być wielorakie; może to być platforma, słabości serwera aplikacji lub problem implementacyjny w postaci niepotrzebnie złożonych WSDL. Może to również oznaczać, że kod wysyła żądanie do bazy danych, która wolno odpowiada.

Testing Aspect- Złożoność analizowania ładunku XML / JSON oznacza, że ​​istnieje potrzeba zwrócenia szczególnej uwagi na testowanie skalowalności. Oznacza to również, że należy dokładnie zbadać pliki WSDL. Jeśli żądania i odpowiedzi są złożone lub większe, lub jeśli zawierają duże załączniki, należy skupić się na podkreśleniu złożoności i zobaczyć, jak zachowuje się pod obciążeniem.

Drugi aspekt

Innym często spotykanym czynnikiem jest bezpieczeństwo. Bezpieczne witryny korzystające z protokołu HTTPS mają znacznie niższą wydajność, a podczas testowania usług internetowych możemy dodać warstwę WSSecurity do warstwy zabezpieczeń HTTP, zmniejszając wydajność jeszcze bardziej.

Testing Aspect- Kwestia środków bezpieczeństwa wymaga skupienia się na testowaniu żądań, które są bezpieczne. Jeśli cała usługa sieciowa jest bezpieczna, oznacza to, że testowanie obciążenia jest ważniejsze, zwłaszcza jeśli używana jest usługa WS-Security i obsługa tokenów.

Load testingto specyficzna forma testów wydajnościowych przeprowadzanych w celu oceny zachowania systemu pod określonym obciążeniem. W SoapUI na ogół używamy terminu „testowanie obciążenia” dla wszystkich typów testów niefunkcjonalnych, jednak SoapUI obsługuje wszystkie typy oceny wydajności usług internetowych, takie jak obciążenie, stres i wytrzymałość.

Zwraca uwagę

• Testowanie obciążenia jest dość wyjątkowe w SoapUI; funkcjonalny przypadek testowy, który umożliwia szybkie tworzenie i modyfikowanie testów wydajnościowych.

• Głównym wyróżnikiem jest to, że testy wydajnościowe w SoapUI są generalnie tworzone na podstawie istniejących testów funkcjonalnych. Pozwala to na szybkie tworzenie zaawansowanych testów wydajnościowych.

• Wydajność usługi sieci Web można sprawdzić w różnych scenariuszach obciążenia. Utrzymuj walidacje funkcjonalne, aby zobaczyć, że nie psują się pod obciążeniem, uruchamiaj kilka testów obciążenia jednocześnie, aby zobaczyć, jak wpływają na siebie nawzajem i wiele więcej.

Tworzenie testu obciążenia

Step 1 - Kliknij prawym przyciskiem myszy Funkcjonalny przypadek testowy i wybierz Nowy test obciążenia.

Step 2 - Wprowadź nazwę testu obciążenia i kliknij OK w kreatorze okna dialogowego.

Test obciążenia zostanie otwarty i zostanie utworzony test obciążenia, jak pokazano na poniższym zrzucie ekranu.

Wykonanie testu obciążenia

Po utworzeniu nowego testu obciążenia jest on wstępnie skonfigurowany tak, aby działał przez 60 sekund (w prawym górnym rogu) z 5 wątkami przy użyciu strategii prostego ładowania.

Zmodyfikuj te wartości zgodnie z wymaganiami i uruchom. Note - Użytkownik powinien być świadomy konfiguracji i koncepcji testowania obciążenia.

Użytkownik zobaczy na środku tabelę statystyk, zaczynając od zbierania danych i po 60 sekundach powinien mieć zakończony LoadTest.

Dodawanie asercji

Step 1 - W edytorze LoadTest wybierz kartę LoadTest Assertion u dołu edytora.

Step 2 - Kliknij przycisk Dodaj potwierdzenie na pasku menu LoadTest Assertion, aby dodać asercję.

Step 3- Otworzy się okno dialogowe Dodaj potwierdzenie. Wybierz Maksymalny krok. Wybierz Maksymalny ustawia maksymalny czas w milisekundach, jaki mogą zająć odpowiedzi, jeśli czas przekroczy ustawiony przez nas, test zakończy się niepowodzeniem. Kliknij OK.

Step 4- Otworzy się okno TestStep Max Assertion. Jak widać na poniższym zrzucie ekranu, zezwalamy na maksymalną odpowiedź wynoszącą jedną sekundę, 1000 milisekund. Nie modyfikujmy niczego. Kliknij OK.

Asercja Maksimum kroku zostanie teraz pomyślnie dodana.

Step 5- Teraz ponownie uruchom test. Jeśli odpowiedzi trwają zbyt długo, powinieneś zobaczyć, jak liczby w kolumnie err szybko się sumują.

Usługa internetowa to zbiór otwartych protokołów i standardów używanych do wymiany danych między aplikacjami lub systemami. Aplikacje napisane w różnych językach programowania i działające na różnych platformach mogą wykorzystywać usługi sieciowe do wymiany danych w sieciach komputerowych, takich jak Internet, w sposób podobny do komunikacji między procesami na jednym komputerze. Ta interoperacyjność (np. Między aplikacjami Java i Python lub Windows i Linux) wynika z wykorzystania otwartych standardów.

Usługi sieciowe oparte na architekturze REST są znane jako usługi sieciowe RESTful. Te usługi internetowe wykorzystują metody HTTP do implementacji koncepcji architektury REST. Usługa internetowa zgodna z REST zwykle definiuje URI (Uniform Resource Identifier), który jest usługą zapewniającą reprezentację zasobów, taką jak JSON i zestaw metod HTTP.

Wszystkie możliwości testowania REST w SoapUI są oparte na logicznej reprezentacji znanej jako usługa REST. Nie powinniśmy w tym miejscu mylić tego terminu z terminem „usługa”, ponieważ nie jest to implementacja usługi, ale odwzorowanie wywoływanej usługi RESTful. Możemy dodać tyle usług REST, ile możemy w projekcie SoapUI. Każdy reprezentuje określoną usługę RESTful. Są następujące -

• REST - Konfiguracja projektu

• REST - WADL

• REST - żądanie

• REST - odpowiedź

• REST - metody HTTP

SoapUI umożliwia zarządzanie operacjami bazy danych za pomocą TestStep o nazwie JDBC Request.

Step 1 - Kliknij prawym przyciskiem myszy TestStep i wybierz Dodaj krok → Żądanie JDBC.

Step 2 - Wprowadź nazwę kroku i kliknij OK.

Dodano krok JDBC. Kliknij dwukrotnie krok, a otworzy się kreator JDBC.

Aby utworzyć połączenie JDBC, użytkownik musi podać prawidłowy sterownik i parametry połączenia. Te parametry służą do identyfikowania typu bazy danych i tworzenia połączenia w celu korzystania z bazy danych.

W przypadku MySQL sterownikiem bazy danych może być com.mysql.jdbc.Driver. Podobnie w przypadku innej bazy danych istnieje predefiniowany sterownik, który można znaleźć w sekcji dokumentów bazy danych.

Step 3 - Parametry połączenia powinny mieć następujący format -

Jdbc:mysql://[host]:[port]/[database]?[property][=value]

Tutaj właściwość to nazwa użytkownika i hasło wraz z innymi parametrami wymaganymi do połączenia z bazą danych.

Na przykład,

jdbc:mysql://localhost:8089/xxx_DB?user=root&password=root

Step 4- Kliknij opcję Testuj połączenie. Po pomyślnym połączeniu wyświetli SUKCES, w przeciwnym razie przedstawi szczegóły niepowodzenia.

JDBC ma własną sekcję Dodaj właściwość, której można używać jako zmiennej w zapytaniu SQL.

Zobaczmy, jak się zachowuje -

Załóżmy, że zapytanie SQL, które musi zostać wykonane w kroku JDBC, to Wybierz * z waluty, gdzie CurrencyCode = 'xxx'.

W tym scenariuszu CurrencyCode można zmienić na podstawie danych wejściowych żądania. Jeśli użytkownik poda wartość zakodowaną na stałe, krok JDBC nie zostanie wykonany dla waluty podanej w żądaniu.

Aby przezwyciężyć takie scenariusze, JDBC obsługuje właściwość add, w której można zdefiniować kod właściwości, który będzie się zmieniał za pomocą kroku przesyłania właściwości.

Zapytanie SQL zostanie uruchomione w oparciu o bieżącą wartość kodu właściwości, a zapytanie SQL sparametryzuje kod CurrencyCode =: Code.

Kliknij Dodaj właściwość + i nazwę jako Kod i podaj wartość lub pozostaw puste, aby użyć kroku Przeniesienie właściwości, aby ją podać.

Żądanie JDBC może również korzystać z większości asercji w TestSteps żądań SOAP. W SoapUI większość tych twierdzeń jest niezależna od TestSteps. W związku z tym potwierdzenia, takie jak Contains i XPath Match, mogą być używane z krokiem testowym żądania JDBC.

Klikając Add an assertion w górnym menu JDBC Request TestStep, użytkownik może dowiedzieć się, jakie asercje są obsługiwane przez TestStep.

Oprócz ogólnych asercji istnieją dwie specyficzne asercje JDBC Request TestStep -

JDBC Timeout - To stwierdzenie może służyć do sprawdzenia, czy bieżące zapytanie SQL jest wykonywane w ramach określonej wartości właściwości Query Timeout.

JDBC Status - Aby sprawdzić, czy instrukcja SQL została wykonana pomyślnie, możemy skorzystać z asercji JDBC Status.

Aby ustawić limit czasu zapytania, podaj wartość odpowiadającą opcji Limit czasu zapytania właściwości po lewej stronie ekranu. Należy pamiętać, że przyjmuje wartości w milisekundach (ms).