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.

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.
- Zawartość właściwości
- Standard statusu zgodności
- Scenariusz
- SLA
- JMS
- Ochrona
Okno dialogowe grupuje wszystkie stwierdzenia w tych kategoriach, jak pokazano na zrzucie ekranu poniżej.

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.
- Liczba asercji jest pokazana na karcie Asercje.
- Aby dodać nową asercję, kliknij przycisk „Dodaj nową asercję”.
Krok 2: Teraz
- Wybierz kategorię asercji.
- Wybierz typ asercji.
- Kliknij „Dodaj”
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.
Krok 4: Po dodaniu natychmiast wykonywane jest potwierdzenie, które pokazuje, czy jest ono prawidłowe czy nieprawidłowe.
Krok 5: Załóżmy teraz, że zmienimy zawartość „Contains Assertion in” SoapUI' na '47' i zobacz co się stanie.
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ę.
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”,
- Wybierz kategorię asercji.
- Wybierz typ asercji – w tym przypadku „NIE zawiera”
- Kliknij „Dodaj”
Krok 2: Sprawdźmy, czy ciąg „intA” istnieje w odpowiedzi. Wprowadź ciąg „FromCurrency” i kliknij „OK”.
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.
Krok 4: Teraz zmieńmy zawartość potwierdzenia „Not Contains” i zobaczmy, co się stanie. Sprawdzimy, czy ciąg „AddResult” nie istnieje.
Krok 5: Ciąg „AddResult” faktycznie znajduje się w odpowiedzi, dlatego potwierdzenie „NOT Contains” nie powiedzie się, jak pokazano poniżej.
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”,
- Wybierz kategorię asercji.
- Wybierz typ asercji – w tym przypadku „Dopasowanie XPath”
- Kliknij „Dodaj”
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.
zadeklaruj mydło przestrzeni nazw='http://schemas.xmlsoap.org/soap/envelope/';
zadeklaruj przestrzeń nazw ns1='http://tempuri.org/';
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.
Krok 4: Do tej pory,
- Po zadeklarowaniu przestrzeni nazw wprowadziliśmy XPath węzła XML, który musimy sprawdzić.
- Musimy kliknąć „Wybierz z bieżącego”, aby bieżąca wartość stała się wartością oczekiwaną.
- Użytkownikowi pokazywana jest aktualna wartość, którą w razie potrzeby możemy zmodyfikować.
- Kliknij „Zapisz”.
Krok 5: Dodane stwierdzenie w SoapUI będą wyświetlane w sposób pokazany poniżej.
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.
Kliknij przycisk „Dodaj asercję”, jak pokazano poniżej.
Krok 2: Teraz wybierz kategorię Twierdzenie.
- W tym przypadku jest to Skrypt.
- Wybierz SoapUI Script Assertion i nie ma z nim żadnych podtypów powiązanych.
- Kliknij „Dodaj”.
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.
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"}
- Kliknij przycisk „Wykonaj”, aby uruchomić wykonanie.
- 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)
- 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.
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.
Krok 6: Teraz
- Wybierz zestaw testów z drzewa Nawigatora
- Kliknij przycisk „Uruchom”.
- Wyniki zostaną wyświetlone dla całego zestawu testów.
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”.
Krok 2: Otworzy się okno dialogowe Dodaj WSDL. Pozostaw pozostałe opcje domyślne i kliknij przycisk „OK”.
Krok 3: Wszystkie operacje przedstawiono poniżej.
Krok 4: Teraz dodajmy Przypadek testowy w tym samym zestawie testów, dla którego stworzyliśmy Testy przelicznik walut.
Krok 5: Wprowadź nazwę przypadku testowego i kliknij przycisk „OK”
Krok 6: Przypadek testowy jest tworzony tak, jak pokazano poniżej.
Krok 7: Dodaj nowy krok testu typu „Żądanie testu mydła”, jak pokazano poniżej.
Krok 8: Wprowadź nazwę kroku testu. Na przykład „Dostawca_w_miejscu”, co będzie bardziej zrozumiałe. Kliknij „OK”.
Krok 9: Wybierz Operaktórą chcielibyśmy zweryfikować. W tym przypadku jest to 'MedicareSupplierSoap -> GetSupplierByCity'. Kliknij 'OK'.
Krok 10: Wprowadź nazwę przypadku testowego i kliknij „OK”.
Krok 11: Zarys żądania XML zostanie wyświetlony w sposób pokazany poniżej.
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
Krok 13: Po wykonaniu testu otrzymujemy poniższą odpowiedź
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.
Krok 15: Teraz kliknij „Dodaj potwierdzenie”,
- W tym przypadku wybierz „Kategorię twierdzenia” – Treść właściwości.
- Wybierz typ asercji jako „Asercja XQuery”
- Kliknij „Dodaj”.
Krok 16: Podobnie jak w przypadku potwierdzenia XPath musimy zadeklarować przestrzeń nazw.
- 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.
- Aby pobrać cały numer dostawcy, musimy napisać zapytanie XPath i umieścić je w <Numer dostawcy> i Tagi.
- Kliknij „Wybierz z bieżącego”, co spowoduje wykonanie na podstawie bieżącej odpowiedzi.
- Po kliknięciu „Wybierz z bieżących” wyświetlona zostanie lista wszystkich numerów dostawców.
- Kliknij „Zapisz”.
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)} }
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'.
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.
Utworzone potwierdzenia pozwalają testerom skonfigurować następujące rzeczy z zestawu narzędzi potwierdzenia.
| Option | OPIS |
| Wybrana asercja przesuwa się w górę kolejności. | |
| Wybrana asercja przesuwa się w dół kolejności. | |
| Usuwa wybrane potwierdzenie | |
| 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.
Odpowiedź zwraca kod błędu zamiast wyniku, jak pokazano poniżej.
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.














































