Twierdzenia w SoapUI: Skrypty, XQuery, Typy XPath

⚡ Inteligentne podsumowanie

Twierdzenia w SoapUI są punktami kontrolnymi decydującymi o tym, czy odpowiedź usługi sieciowej jest poprawna, zmieniając żądanie, które jest jedynie wykonywane, w test, który faktycznie kończy się powodzeniem lub niepowodzeniem na rzeczywistej, weryfikowalnej treści.

  • 🔘 Kategorie: Zawartość nieruchomości, zgodność/status/standardy, skrypt, SLA, JMS i bezpieczeństwo.
  • Zawiera: Potwierdza istnienie ciągu w odpowiedzi, z obsługą wyrażeń regularnych.
  • Nie zawiera: Potwierdza brak ciągu znaków, przydatne w przypadku tokenów błędów i pól wyciekających.
  • 🧪 Dopasowanie XPath: Najpierw zadeklaruj przestrzeń nazw, następnie wybierz jeden węzeł i porównaj jego wartości.
  • 🛠️. Dopasowanie XQuery: Sprawdza poprawność powtarzających się zestawów węzłów, które w przeciwnym razie wymagałyby setek sprawdzeń XPath.
  • 📊 Scenariusz: Groovy asercje obsługują dynamiczne odpowiedzi oraz logikę konfiguracji lub demontażu.
  • 🔍 Rozwiązywanie problemów: Najczęstszą przyczyną błędów jest nieprawidłowa przestrzeń nazw i składnia z kropką zamiast dwukropka.

Twierdzenia w SoapUI

Co to jest twierdzenie?

Asercja oznacza akt potwierdzenia lub stwierdzenia czegoś. Można go również interpretować jako punkt kontrolny lub punkt walidacji.

Po wysłaniu żądania do serwera WWW otrzymujemy odpowiedź. Musimy zweryfikować, czy odpowiedź zawiera oczekiwane dane. Aby to zrobić, musimy użyć asercji. Bez asercji krok testowy udowadnia jedynie, że usługa odpowiedziała, a nie, że odpowiedziała poprawnie, dlatego każdy… Test API powinien mieć przy sobie co najmniej jedną.

Rodzaje asercji

Istnieją różne sposoby wyrażania odpowiedzi, jednak skupimy się na najczęściej stosowanych SoapUI Typy asercji podczas walidacji odpowiedzi. Poniżej znajdują się kategorie dostępne w wersji Open Source. SoapUI.

  1. Zawartość właściwości
  2. Standard statusu zgodności
  3. Scenariusz
  4. SLA
  5. JMS
  6. Ochrona

Okno dialogowe grupuje wszystkie stwierdzenia w tych kategoriach, jak pokazano na zrzucie ekranu poniżej.

Kategorie twierdzeń wymienione w SoapUI Dodaj okno dialogowe potwierdzenia
Rodzaje twierdzeń w SoapUI

Oprócz wymienionych powyżej opcji, wersja Pro ma także wbudowaną funkcję JDBC Assertion, dzięki której możemy sprawdzić, czy usługa internetowa poprawnie zaktualizowała bazę danych.

Uwaga dotycząca wersji: aktualne SoapUI dokumentacja zawiera również listę JDBC kategoria (Status JDBC i Limit czasu JDBC) obok powyższych kategorii i Treść wiadomości Asercja wewnątrz zawartości właściwości dla bogatszego porównania XML. Wersja komercyjna, określana tutaj jako „Pro”, jest teraz sprzedawana jako ReadyAPI przez SmartBear, więc etykiety menu w nowszych kompilacjach mogą wyglądać inaczej, podczas gdy zachowanie asercji pozostaje takie samo.

Zawiera twierdzenie

Wyszukuje istnienie określonego ciągu. Obsługuje również wyrażenia regularne.

Będziemy kontynuować ten sam przykład z poprzedniego samouczka z żądaniem WSDL http://www.dneonline.com/calculator.asmxJeśli jeszcze nie zbudowałeś tego projektu, przepracuj go tworzenie projektu, zestawu testów i przypadku testowego pierwszy.

Krok 1: Domyślnie nie ma żadnych asercji.

  1. Liczba asercji jest pokazana na karcie Asercje.
  2. Aby dodać nową asercję, kliknij przycisk „Dodaj nową asercję”.

SoapUI Karta Asercje, na której nie ma żadnych asercji i znajduje się przycisk Dodaj nową asercję

Krok 2: Teraz

  1. Wybierz kategorię asercji.
  2. Wybierz typ asercji.
  3. Kliknij „Dodaj”

Dodaj okno dialogowe potwierdzenia z wybraną kategorią i typem potwierdzenia

Krok 3: Sprawdźmy, czy ciąg „46” znajduje się w odpowiedzi. Kliknij „OK”.

Uwaga: Możemy także zignorować wielkość liter i dodać wyrażenie regularne.

Zawiera okno dialogowe konfiguracji potwierdzenia z wprowadzoną wartością 46

Krok 4: Po dodaniu natychmiast wykonywane jest potwierdzenie, które pokazuje, czy jest ono prawidłowe czy nieprawidłowe.

Karta Asercje raportująca asercję Zawiera jako WAŻNA

Krok 5: Załóżmy teraz, że zmienimy zawartość „Contains Assertion in” SoapUI' na '47' i zobacz co się stanie.

Edycja zawartości potwierdzenia Contains z 46 na 47

Krok 6: Asercja jest wykonywana, a wynik jest wyświetlany użytkownikowi. Ponieważ w odpowiedzi nie ma ciągu „47”, asercja nie powiodła się.

Karta Asercje zgłaszająca, że ​​asercja Zawiera jest nieudana

Nie zawiera twierdzeń

Jego odpowiednik działa w drugą stronę. Wyszukuje nieistnienie określonego ciągu znaków. Obsługuje również wyrażenia regularne.

Krok 1: Teraz po kliknięciu przycisku „Dodaj nowe potwierdzenia”,

  1. Wybierz kategorię asercji.
  2. Wybierz typ asercji – w tym przypadku „NIE zawiera”
  3. Kliknij „Dodaj”

Dodaj okno dialogowe potwierdzenia z opcją NIE zawiera wybranych

Krok 2: Sprawdźmy, czy ciąg „intA” istnieje w odpowiedzi. Wprowadź ciąg „FromCurrency” i kliknij „OK”.

Okno dialogowe potwierdzenia „Nie zawiera” z wprowadzonym ciągiem FromCurrency

Krok 3: Po dodaniu asercji, jest ona wykonywana i wyświetla wynik. Do tej pory dodaliśmy dwie asercje, więc obie są wykonywane i wyświetlają wynik.

Karta Potwierdzenia zawierająca wyniki Zawiera i Nie zawiera

Krok 4: Teraz zmieńmy zawartość potwierdzenia „Not Contains” i zobaczmy, co się stanie. Sprawdzimy, czy ciąg „AddResult” nie istnieje.

Nie zawiera dialogu potwierdzenia sprawdzającego token AddResult

Krok 5: Ciąg „AddResult” faktycznie znajduje się w odpowiedzi, dlatego potwierdzenie „NOT Contains” nie powiedzie się, jak pokazano poniżej.

Nie zawiera potwierdzenia, które nie powiodło się, ponieważ obecny jest AddResult

Asercja dopasowania XPath

Dopasowanie ciągów znaków jest nieprecyzyjne, dlatego następne potwierdzenie dotyczy pojedynczego węzła. Używa wyrażenia XPath do wybrania węzła docelowego i jego wartości. XPath, jest językiem zapytań XML umożliwiającym wybieranie węzłów z dokumentu XML.

Krok 1: Teraz po kliknięciu przycisku „Dodaj nowe potwierdzenia”,

  1. Wybierz kategorię asercji.
  2. Wybierz typ asercji – w tym przypadku „Dopasowanie XPath”
  3. Kliknij „Dodaj”

Dodaj okno dialogowe potwierdzenia z wybranym dopasowaniem XPath

Krok 2: Dodaj okno XPath. Otwiera się okno.

Przed dodaniem SoapUI W XPath musimy zadeklarować przestrzeń nazw. Przestrzeń nazw XML to zbiór nazw, identyfikowanych przez odniesienie do Uniform Resource Identifier (URI), które są używane w dokumentach XML jako nazwy elementów i atrybutów. Ten sam identyfikator jest używany w SoapUI Asercja XPath.

Aby zadeklarować przestrzeń nazw XML, wystarczy kliknąć przycisk „Deklaruj”, który wykona zadanie za nas. W przeciwnym razie możemy ręcznie zadeklarować przestrzeń nazw.

Po zadeklarowaniu przestrzeni nazw musimy odwołać się do XPath, używając utworzonej przestrzeni nazw.

Po kliknięciu przycisku „Deklaruj” pojawią się dwie przestrzenie nazw, ponieważ mamy dwa adresy URI. Jednym z nich jest schemat URL a drugi odpowiada faktycznej usłudze sieciowej URL. Podczas odwoływania się do XPath musimy używać rzeczywistej przestrzeni nazw, w której znajduje się usługa sieciowa, a NIE przestrzeni nazw schematu. Zadeklarowane wiersze pojawiają się u góry pola XPath, jak pokazano poniżej.

Zadeklarowano przestrzenie nazw soap i ns1 w oknie asercji XPath

zadeklaruj mydło przestrzeni nazw='http://schemas.xmlsoap.org/soap/envelope/';

zadeklaruj przestrzeń nazw ns1='http://tempuri.org/';

Okno potwierdzenia XPath zaraz po kliknięciu Deklaruj

Krok 3: Teraz musimy wprowadzić XPath węzła XML, który chcemy zweryfikować.

//ns1:AddResult Podaje nam wartość węzła zawartego pomiędzy & a ns1 odpowiada zadeklarowanej przestrzeni nazw, która wskazuje na „http://tempuri.org/”

Po wprowadzeniu kodu XML musimy kliknąć opcję „Wybierz z bieżącej”, aby wartość z bieżącej odpowiedzi została pobrana do porównania w przyszłości.

Wyrażenie XPath wprowadzone za pomocą opcji Wybierz z bieżącego podświetlenia

Krok 4: Do tej pory,

  1. Po zadeklarowaniu przestrzeni nazw wprowadziliśmy XPath węzła XML, który musimy sprawdzić.
  2. Musimy kliknąć „Wybierz z bieżącego”, aby bieżąca wartość stała się wartością oczekiwaną.
  3. Użytkownikowi pokazywana jest aktualna wartość, którą w razie potrzeby możemy zmodyfikować.
  4. Kliknij „Zapisz”.

Konfiguracja dopasowania XPath pokazująca oczekiwaną wartość i przycisk Zapisz

Krok 5: Dodane stwierdzenie w SoapUI będą wyświetlane w sposób pokazany poniżej.

Karta Asercje pokazująca dodane potwierdzenie dopasowania XPath

Twierdzenia skryptowe

Ta technika asercji jest najpowszechniej stosowana, ponieważ niezwykle trudno jest zarządzać i utrzymywać setki asercji.

SoapUI używa albo Groovy Skrypty lub JAVASCRIPT do tworzenia skryptów asercji. Technika tworzenia skryptów jest stosowana w celu rozwojuping Struktura do testowania protokołu SOAP. Asercje skryptowe są używane w następujących okolicznościach.

  • Skrypty pozwalają użytkownikowi na wykonywanie pewnych operacji przed i po wykonaniu przypadku testowego za pomocą odpowiednio metod „set up” i „tear down”. „Set up” to procedura wykonywana przed wykonaniem określonej metody (na przykład: tworzenie i inicjalizacja obiektu), natomiast „tear down” to procedura wykonywana po wykonaniu metody (np.: niszczenie obiektów i czyszczenie). Ta funkcja nie jest dostępna w innych typach asercji i można ją wykonać wyłącznie poprzez kodowanie.
  • Umożliwia użytkownikom otwieranie/zamykanie projektu, inicjalizację lub czyszczenie ustawień związanych z projektem, a także pracę ze zmiennymi środowiskowymi, co jest bardzo przydatne podczas pisania skryptów.
  • Pomaga nam to w zapewnieniu dynamicznej treści odpowiedzi.
  • Asercje skryptowe służą do tworzenia asercji zdefiniowanych przez użytkownika, które NIE są wstępnie zdefiniowane przez SoapUI.

Aby zademonstrować stwierdzenie skryptu w SoapUI, skorzystamy z kalkulatora WSDL, przypadku testowego „Dodaj”, który stworzyliśmy wcześniej.

Krok 1: Dodawanie skryptu Groovy jest takie samo, jak w przypadku innych asercji, z tą różnicą, że asercja nie jest predefiniowana. Jest to asercja zdefiniowana przez użytkownika, która oferuje większą elastyczność niż asercje wbudowane.

Wybierz krok testu, do którego ma zostać dodane potwierdzenie.

Wybrany krok testowy SoapUI nawigator przed dodaniem potwierdzenia

Kliknij przycisk „Dodaj asercję”, jak pokazano poniżej.

Dodaj przycisk potwierdzenia na pasku narzędzi potwierdzenia kroku testu

Krok 2: Teraz wybierz kategorię Twierdzenie.

  1. W tym przypadku jest to Skrypt.
  2. Wybierz SoapUI Script Assertion i nie ma z nim żadnych podtypów powiązanych.
  3. Kliknij „Dodaj”.

Dodaj okno dialogowe potwierdzenia z wybraną kategorią skryptu

Krok 3: Otwiera się okno dialogowe Skrypty, w którym użytkownik będzie mógł napisać zdefiniowany przez siebie skrypt w celu sprawdzenia poprawności odpowiedzi XML.

pusty SoapUI okno dialogowe edytora asercji skryptu

Krok 4: Teraz napiszmy świetny skrypt do walidacji współczynnika konwersji. Skrypt wraz z osadzonymi komentarzami znajduje się poniżej. Zalecana jest znajomość… Java Skrypt lub Groovy Skrypt przed próbą napisania własnego skryptu.

//Define Groovy Utils and holder for validating the XML reponse content
def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context)
def holder = groovyUtils.getXmlHolder(messageExchange.responseContent)

//Define the NameSpace
holder.namespaces["ns1"] = "http://tempuri.org/"

//Get the Value of the Node 'AddResult' and assign to a variable
def addResult = holder.getNodeValue("//ns1:AddResult")

//print the value of the result in the Output panel
log.info "The result value for integers is " + addResult

//Comparing the value to print 'Pass' or 'Fail'
if(addResult=="46")
{ log.info "Pass" }
else
{ log.info "fail"}
  1. Kliknij przycisk „Wykonaj”, aby uruchomić wykonanie.
  2. Dane wyjściowe skryptu są wyświetlane w panelu Dane wyjściowe. Wydrukował zarówno wartość konwersji, jak i wynik końcowy (pozytywny lub negatywny)
  3. Wyświetla się informacja, że ​​'Script Assertion Passed'. Kliknij OK.

Uwaga: Ostateczne wyskakujące okienko z informacjami będzie zawsze wyświetlane z komunikatem „Potwierdzenie skryptu przekazane”, o ile skrypt jest poprawny składniowo. Nie ma to żadnego związku z twoim twierdzeniem zawartym w skrypcie.

Panel wyjściowy potwierdzenia skryptu drukujący wartość wyniku i przekazujący

kliknij OK

Krok 5: Teraz karta asercji wyświetla wszystkie asercje, które dodaliśmy do tego zestawu testów, wraz ze statusem każdej z nich.

Karta Asercje zawierająca listę wszystkich asercji dodanych do zestawu testów

Krok 6: Teraz

  1. Wybierz zestaw testów z drzewa Nawigatora
  2. Kliknij przycisk „Uruchom”.
  3. Wyniki zostaną wyświetlone dla całego zestawu testów.

Wyniki uruchomienia zestawu testów po wykonaniu wszystkich asercji

Asercja dopasowania XQuery

Używa wyrażenia XQuery do wybierania zawartości z właściwości docelowej. Potrzebujemy znacznie obszerniejszego pliku XML odpowiedzi, aby lepiej zrozumieć asercję XQuery w SoapUI. Zaimportujmy jeszcze jeden plik WSDL, jak pokazano poniżej: http://www.webservicex.net/medicareSupplier.asmx?WSDL

Uwaga: Publiczne punkty końcowe demonstracyjne webservicex.net używane w tym przewodniku nie są już niezawodnie osiągalne, dlatego poniższe zrzuty ekranu z żądaniami i odpowiedziami służą jako przykład referencyjny. Każdy kod WSDL zwracający powtarzający się zestaw węzłów będzie testował asercję XQuery w dokładnie taki sam sposób.

Krok 1: Kliknij prawym przyciskiem myszy istniejący projekt i wybierz opcję „Dodaj WSDL”.

Menu prawego przycisku myszy SoapUI projekt pokazujący Dodaj WSDL

Krok 2: Otworzy się okno dialogowe Dodaj WSDL. Pozostaw pozostałe opcje domyślne i kliknij przycisk „OK”.

Dodaj okno dialogowe WSDL z domyślnymi opcjami importu

Krok 3: Wszystkie operacje przedstawiono poniżej.

Operacje WSDL dostawcy Medicare wymienione w drzewie nawigacyjnym

Krok 4: Teraz dodajmy Przypadek testowy w tym samym zestawie testów, dla którego stworzyliśmy Testy przelicznik walut.

Nowa opcja TestCase w istniejącym zestawie testów

Krok 5: Wprowadź nazwę przypadku testowego i kliknij przycisk „OK”

Wprowadzanie nazwy przypadku testowego w oknie dialogowym Nowy przypadek testowy

Krok 6: Przypadek testowy jest tworzony tak, jak pokazano poniżej.

Nowo utworzony przypadek testowy w SoapUI drzewo nawigatora

Krok 7: Dodaj nowy krok testu typu „Żądanie testu mydła”, jak pokazano poniżej.

Dodaj menu Krok z wybranym żądaniem testu SOAP

Krok 8: Wprowadź nazwę kroku testu. Na przykład „Dostawca_w_miejscu”, co będzie bardziej zrozumiałe. Kliknij „OK”.

Nadawanie nowej nazwie kroku testu Dostawca_według_miasta

Krok 9: Wybierz Operaktórą chcielibyśmy zweryfikować. W tym przypadku jest to 'MedicareSupplierSoap -> GetSupplierByCity'. Kliknij 'OK'.

Wybieranie operacji GetSupplierByCity dla kroku testowego

Krok 10: Wprowadź nazwę przypadku testowego i kliknij „OK”.

Potwierdzanie nazwy żądania testu SOAP

Krok 11: Zarys żądania XML zostanie wyświetlony w sposób pokazany poniżej.

Wygenerowano zarys żądania GetSupplierByCity w formacie XML

Krok 12: Teraz znajdźmy informacje o wszystkich dostawcach dla miasta „Nowy Jork”.

Aby to zrobić, dodaj następujące wiersze do swojego kodu.

<GetSupplierByCity xmlns="http://www.webservicex.net/">

<City>New York</City>

</GetSupplierByCity>

WSDL poniżej URL – http://www.webservicex.net/medicareSupplier.asmx?op=GetSupplierByCity

Żądanie XML edytowane z Nowym Jorkiem jako wartością miasta

Krok 13: Po wykonaniu testu otrzymujemy poniższą odpowiedź

Odpowiedź GetSupplierByCity zawierająca powtarzające się rekordy dostawców

Krok 14: Załóżmy, że musimy zweryfikować wszystkie numery dostawców. Nie możemy użyć asercji XPath, ponieważ potrzebujemy setek asercji XPath. Dlatego użycie XQuery jest w tym przypadku nieuniknione.

Asercja XQuery pomaga nam zweryfikować grupę odpowiedzi XML, które mają charakter powtarzalny.

Powtarzające się węzły SupplierData, po których XQuery będzie iterować

Krok 15: Teraz kliknij „Dodaj potwierdzenie”,

  1. W tym przypadku wybierz „Kategorię twierdzenia” – Treść właściwości.
  2. Wybierz typ asercji jako „Asercja XQuery”
  3. Kliknij „Dodaj”.

Wybrano opcję Asercja XQuery w kategorii Zawartość właściwości

Krok 16: Podobnie jak w przypadku potwierdzenia XPath musimy zadeklarować przestrzeń nazw.

  1. Kliknij przycisk „Deklaruj”, aby automatycznie zezwolić SoapUI Aby zadeklarować przestrzeń nazw. Po kliknięciu przycisku „Deklaruj” użytkownikowi wyświetli się komunikat „Zamiast tego zadeklaruj przestrzeń nazw ze schematu”. Kliknij „Tak”, aby kontynuować, jak pokazano poniżej.
  2. Aby pobrać cały numer dostawcy, musimy napisać zapytanie XPath i umieścić je w <Numer dostawcy> i Tagi.
  3. Kliknij „Wybierz z bieżącego”, co spowoduje wykonanie na podstawie bieżącej odpowiedzi.
  4. Po kliknięciu „Wybierz z bieżących” wyświetlona zostanie lista wszystkich numerów dostawców.
  5. Kliknij „Zapisz”.

Deklarowanie przestrzeni nazw z okna podręcznego potwierdzenia schematu

Uwaga: po kliknięciu przycisku „Deklaruj” mogą pojawić się różne URLjest deklaracją przestrzeni nazw, jednak rzeczywista przestrzeń nazw lokalizacji usługi sieciowej jest tym, co byłoby brane pod uwagę w kodowaniu.

Gotowe wyrażenie XQuery z deklaracjami przestrzeni nazw wygląda następująco.

// Namespace declaration
declare namespace soap='http://schemas.xmlsoap.org/soap/envelope/';
declare namespace ns1='http://www.webservicex.net/';
declare namespace x = '';

// Placing the result in Myresult Tags

{
// Iterating through all the supplier number
for $x in //ns1:GetSupplierByCityResponse/ns1:SupplierDataLists/ns1:SupplierDatas/ns1:SupplierData

//Return all the Supplier number within ‘SupplierNumber’ Tags.
return {data($x/ns1:SupplierNumber)}
}

Okno wyrażeń XQuery zawierające listę wszystkich numerów dostawców

Krok 17: Asercja XQuery jest wykonywana i wyświetla wynik końcowy w panelu „Assertion”, jak pokazano poniżej. Właśnie pomyślnie dodaliśmy asercję XQuery, za pomocą której zweryfikowaliśmy wszystkie informacje o numerze dostawcy. Dane te będą porównywane z danymi rzeczywistymi za każdym razem, gdy żądanie zostanie wysłane do serwera WWW.

Uwaga: Rzeczywiste wartości nie zostaną wyświetlone. Jeśli wszystkie rzeczywiste wartości są takie same jak oczekiwane wartości, wyświetla się VALID, w przeciwnym razie wyświetla się 'Failed'.

Panel asercji pokazujący wynik asercji XQuery

Kiedy używać wbudowanej asercji?

Mając do dyspozycji zarówno opcje „wskaż i kliknij”, jak i opcje skryptowe, pojawia się praktyczne pytanie, którą z nich wybrać.

  • Gdy odpowiedź jest krótka i można ją zweryfikować za pomocą jednej z wbudowanych asercji.
  • Możemy również użyć wbudowanej asercji, jeśli odpowiedź wysyłana z serwera WWW ma zawsze charakter statyczny. Jeśli jest dynamiczny, nie będziemy w stanie go potwierdzić za pomocą wbudowanych asercji.
  • Kiedy użycie wbudowanych potwierdzeń, takich jak potwierdzenia przekroczenia limitu czasu i potwierdzenia zabezpieczeń, staje się nieuniknione.
  • Wbudowane twierdzenia sprawdzają się całkiem dobrze w przypadku jednorazowego użycia, gdy testów nie trzeba powtarzać.

Opcje asercji

Utworzonymi asercjami najlepiej sterować za pomocą panelu sterowania, który został podświetlony poniżej.

Panel sterowania skrzynki narzędziowej Assertions w SoapUI

Utworzone potwierdzenia pozwalają testerom skonfigurować następujące rzeczy z zestawu narzędzi potwierdzenia.

Option OPIS
Przesuń ikonę potwierdzenia w górę Wybrana asercja przesuwa się w górę kolejności.
Przesuń ikonę potwierdzenia w dół Wybrana asercja przesuwa się w dół kolejności.
Usuń ikonę potwierdzenia Usuwa wybrane potwierdzenie
Konfiguruj lub edytuj ikonę potwierdzenia Skonfiguruj ponownie/edytuj wybraną asercję.

Poniżej znajdują się funkcje dostępne wyłącznie w wersji Pro SoapUI, teraz wysyłane jako ReadyAPIWersja Pro pomaga nam również grupować asercje, dzięki czemu możemy dodać kolejną warstwę walidacji do utworzonych asercji.

  • I: Wszystkie potwierdzenia są oceniane jako poprawne, co skutkuje pozytywnym wynikiem warunku grupy.
  • LUB: Przynajmniej jedno z stwierdzeń w grupie musi być WAŻNE, aby można było stwierdzić, że grupa spełnia warunek PASSED.
  • Wersja Pro również pozwala Klonowanie twierdzeń:Ta opcja umożliwia testerom zezwolenie na kopiowanie potwierdzenia do innego kroku testu w tym samym lub innym projekcie.
  • Wyłącz/Włącz asercje: Ta opcja umożliwia wyłączenie lub włączenie dowolnej asercji zgrupowanej lub niezgrupowanej. Jeśli asercja jest wyłączona, jest ona wyszarzona, a po wykonaniu przypadku testowego wyłączone asercje nie zostaną wykonane.
  • Rozgrupowywanie asercji: Wszelkie zgrupowane asercje można rozgrupować, jeśli testerzy podejmą taką decyzję.

Pełna lista metod dostępnych w różnych typach asercji

Poniższa tabela zawiera wszystkie omówione powyżej stwierdzenia, pogrupowane według kategorii, w której występują w oknie dialogowym Dodaj stwierdzenie.

Mechanizm potwierdzania OPIS
ZAWARTOŚĆ NIERUCHOMOŚCI
zawiera Wyszukuje istnienie określonego ciągu. Obsługuje również wyrażenia regularne.
Nie zawiera Wyszukuje nieistnienie określonego ciągu. Obsługuje również wyrażenia regularne.
Dopasowanie XPath Używa wyrażenia XPath do wybrania węzła docelowego i jego wartości.
Dopasowanie XQuery Używa wyrażenia XQuery w celu wybrania zawartości z właściwości docelowej.
Zgodność, status, standardy
HTTP Pobierz wszystkie zasoby Sprawdza dokument HTML po pobraniu i sprawdza każdą właściwość zawierającą HTML.
Nieprawidłowy status HTTP Codes Sprawdza, czy odpowiedź HTML zawiera kod stanu, którego nie ma na liście zdefiniowanych kodów.
Nie błąd SOAP Sprawdza, czy ostatnia odebrana wiadomość nie jest błędem protokołu SOAP. Jest bardzo oczywiste, że ma to zastosowanie tylko w przypadku kroków testowych SOAP.
Zgodność schematu Sprawdza, czy ostatnia odebrana wiadomość jest zgodna ze standardową definicją schematu WSDL lub WADL. Sprawdza się dobrze w przypadku kroków testowych SOAP i REST.
Błąd SOAP-a Sprawdza, czy ostatnia odebrana wiadomość jest błędem protokołu SOAP. Jest to odwrotność stwierdzeń o błędach „NIE SOAP”.
Odpowiedź SOAP Sprawdza, czy ostatnia otrzymana odpowiedź jest prawidłową odpowiedzią SOAP i obowiązuje tylko w przypadku kroków żądania testu SOAP.
Prawidłowy status HTTP Codes Sprawdza, czy odpowiedź HTML zawiera kod statusu znajdujący się na liście zdefiniowanych kodów. Jest to odwrotność kodu „Nieprawidłowy status HTTP”. CodeTwierdzenie s.
Żądanie adresowania WS Sprawdza, czy ostatnie otrzymane żądanie zawiera odpowiednie nagłówki adresowania WS.
Odpowiedź adresowania WS Sprawdza, czy ostatnia otrzymana odpowiedź zawiera odpowiednie nagłówki adresowania WS.
Stan zabezpieczeń WS Sprawdza, czy ostatnia odebrana wiadomość zawiera prawidłowe nagłówki WS-Security i jest ważna tylko w przypadku żądań SOAP.
Scenariusz
Twierdzenie skryptu Umożliwia użytkownikom wykonanie niestandardowego skryptu w celu przeprowadzenia weryfikacji zdefiniowanej przez użytkownika.
SLA
Umowa SLA odpowiedzi Sprawdza, czy czas odpowiedzi ostatniej otrzymanej odpowiedzi mieścił się w zdefiniowanym limicie.
JMS
Stan JMS Sprawdza, czy żądanie JMS z kroku testowego zostało pomyślnie wykonane i działa prawidłowo w przypadku kroków testowych z punktem końcowym JMS.
Limit czasu JMS Sprawdza, czy odpowiedź JMS w kroku testu nie trwała dłużej niż określony czas.
Ochrona
Ekspozycja informacji wrażliwych Sprawdza, czy komunikat odpowiedzi nie ujawnia poufnych informacji o systemie docelowym. Możemy użyć tego potwierdzenia dla kroków testowych REST, SOAP i HTTP.

POBIERZ PROJEKT SOAPUI ZAWIERAJĄCY POWYŻSZE TWIERDZENIA

Typowe błędy i rozwiązywanie problemów

Większość niepowodzeń w twierdzeniach tracWracając do małego zestawu błędów, sprawdź je przed przepisaniem wyrażenia.

  • Użyj prawidłowej przestrzeni nazw. Przestrzeń nazw powinna być URL gdzie znajduje się usługa internetowa.
  • Jeśli podczas tworzenia wystąpi błądping w skrypcie użyj 'log.info', aby wydrukować zawartość zmiennych.
  • Jeśli nie otrzymano oczekiwanych wyników, sprawdź, czy w żądaniu przekazano prawidłowe dane wejściowe.

Na przykład, w konwerterze walut, jeśli wprowadzisz „intA” jako „x”, które nie jest liczbą całkowitą, na wyjściu pojawi się kod błędu „SOAP-Client”, co oznacza, że ​​problem dotyczy parametru przekazywanego przez klienta. Żądanie zawierające nieprawidłową wartość jest wyświetlane jako pierwsze.

SoapUI żądanie przekazania nieprawidłowej wartości innej niż całkowita dla intA

Odpowiedź zwraca kod błędu zamiast wyniku, jak pokazano poniżej.

Kod błędu klienta SOAP zwrócony w SoapUI edytor odpowiedzi

Upewnij się, że używasz poprawnej składni podczas korzystania z asercji XPath i XQuery. NIE należy używać kropki(.) zamiast dwukropka(:) podczas korzystania z powyższej asercji. Składnia to //namespace:Tagname, a NIE //namespace.tagname. W ten sposób możesz otrzymać komunikat „BRAK dopasowania w bieżącej odpowiedzi”, mimo że nazwa tagu jest poprawna.

Brak dopasowania w bieżącej odpowiedzi, błąd spowodowany nieprawidłową składnią XPath

FAQ

Dowolna liczba. SoapUI stosuje każde potwierdzenie dołączone do kroku testu próbnika po jego wykonaniu, a krok jest oznaczany jako nieudany w widoku przypadku testowego, jeśli choć jedno z tych potwierdzeń się nie powiedzie.

Porównuje komunikat XML z oczekiwanym dokumentem węzeł po węźle, dzięki czemu wybrane pola można zignorować lub dopasować luźno zamiast traktować cały ładunek jako jeden zwykły ciąg znaków.

Open-source SoapUI obejmuje zawartość nieruchomości, zgodność, skrypt, SLA, JMS i bezpieczeństwo. ReadyAPI dodaje grupęping, klonowanie, sprawdzanie JDBC oraz włączanie i wyłączanie sterowania.

Modele sztucznej inteligencji odczytują przykładową odpowiedź i sugerują wyrażenia XPath lub XQuery, proponują wartości graniczne i oznaczają pola, które zmieniają się przy każdym przebiegu — znacznie ograniczając pracę związaną z ręcznym pisaniem przestrzeni nazw i wyrażeń.

Tak. Drugi pilot autouzupełnianie GroovySzablon narzędzi i XmlHolder. Zawsze wykonuj skrypt jako pierwszy, ponieważ poprawny składniowo skrypt zgłasza, że ​​Script Assertion Passed (Asercja skryptu została zaliczona), niezależnie od porównania.

Tak. Pola zawartości asercji obsługują rozszerzanie właściwości, dzięki czemu oczekiwaną wartość można pobrać z właściwości projektu lub przypadku testowego, a nie z wartości literałowej. Dzięki temu jedno asercja nadaje się do wielokrotnego użytku w różnych środowiskach.

Nieudane potwierdzenie oznacza krok testu jako nieudany w widoku przypadku testowego i zapisuje odpowiadający mu wpis FAILED ze szczegółami błędu w dzienniku wykonywania testów u dołu okna.

Zawiera, Nie zawiera, Zgodność XPath, Zgodność XQuery, SLA odpowiedzi, Skrypt, prawidłowe i nieprawidłowe kody stanu HTTP, Ujawnienie poufnych informacji oraz Zgodność schematu ze schematem WADL lub wnioskowanym schematem.

Podsumuj ten post następująco: