• Articles
• admin

w poprzednich dwóch artykułach omówiliśmy szczegóły twierdzeń specyficznych dla testu, które miały zastosowanie tylko do określonego rodzaju TestCase lub WebService w trakcie testu. Wszystkie twierdzenia wymienione w artykule ” SoapUI Test Specific Assertions: REST Services „mają zastosowanie tylko do usług internetowych REST, a wszystkie twierdzenia wymienione w artykule” SoapUI Test Specific Assertions: Soap Services ” mają zastosowanie tylko do usług internetowych SOAP. SoapUI zawiera również kilka innych twierdzeń, które mają zastosowanie zarówno do usług SOAP, jak i do usług odpoczynku i są znane jako wspólne twierdzenia SoapUI. W tym artykule zrozumiemy użycie wszystkich tych typowych twierdzeń, obejmując szczegóły w następujących tematach:

• jakie są twierdzenia dotyczące treści właściwości wspólnych w SoapUI?
  • co zawiera w SoapUI?
  • dodatkowo czego nie ma w SoapUI?
  • co to jest XPath Assertion w SoapUI?
  • co to jest XQuery Match Assertionin SoapUI?
• podobnie, jakie są wspólne Zgodność, Status i standardowe twierdzenia w SoapUI?
  • jakie są asercje kodów statusu HTTP dostarczane przez SoapUI?
  • dodatkowo, co to jest twierdzenie zgodności schematu w SoapUI?
• jakie są wspólne twierdzenia SLA w SoapUI?

ponieważ wszystkie te twierdzenia mają zastosowanie zarówno do usług SOAP, jak i REST, będziemy używać następujących informacji do walidacji wszystkich tych twierdzeń:

• projekt Rest utworzony przy użyciu URI: „http://bookstore.toolsqa.com/BookStore/v1/Books „i projekt SOAP stworzony przy użyciu WSDL:” http://bookstore.toolsqa.com/BookStoreService.wsdl „zgodnie ze szczegółami wymienionymi w artykule” SoapUI: praca z projektami.”
• możesz odnieść się do przykładowego wyniku projektu REST z artykułu” SoapUI Test Specific Assertions: REST Services „oraz przykładowego wyniku projektu SOAP z artykułu”SoapUI Test Specific Assertions: SOAP Services”.

jakie są twierdzenia dotyczące właściwości wspólnych w SoapUI?

jak już wiemy, Assertions zawartości właściwości walidują treść otrzymanej odpowiedzi. SoapUI zapewnia wiele twierdzeń dotyczących treści, które mają zastosowanie zarówno do żądań SOAP, jak i REST. Zobaczmy w poniższych sekcjach, jak możemy użyć tych twierdzeń?

co zawiera w SoapUI?

twierdzenie Contains wyszukuje istnienie tokenu łańcuchowego w wartości właściwości.

zastanów się nad scenariuszem, że w serwisie księgarni musimy sprawdzić, czy istnieje książka o nazwisku autora „Richard E. Silverman”?Wykonajmy kroki wymienione poniżej, aby zweryfikować to samo za pomocą twierdzenia „Contains” :

1. najpierw przejdź do okna dialogowego Dodaj twierdzenie. Następnie kliknij twierdzenie” zawiera „w kategorii twierdzenie „zawartość właściwości”, jak zaznaczono poniżej:

1. Po Drugie, kliknij przycisk” Dodaj”, a wyświetli się okno dialogowe „zawiera twierdzenie”, jak pokazano poniżej:

1. Po Trzecie, wpisz nazwisko autora „Richard E. Silverman” w sekcji „Treść”. Jest to szukany ciąg, który chcesz zweryfikować w odpowiedzi WebService.

2. Po czwarte, w powyższym oknie dialogowym zobaczysz również dwa pola wyboru. Są to:

• Ignoruj wielkość liter: jeśli zaznaczysz pole Ignoruj wielkość liter, poprawi to ciąg znaków, ignorując wielkość liter. Załóżmy, że w polu tekstowym treści wpisujesz „richARD E. SilVerMan „i zaznaczasz pole wyboru” Ignoruj wielkość liter w porównaniu”. Dodatkowo zignoruje wielkość liter i sprawdzi tylko wartość wprowadzonego ciągu znaków.

tak więc, twierdzenie przejdzie jako znaki w łańcuchu są takie same, jeśli zignorujemy wielkość liter.

• Wyrażenie regularne: jeśli chcesz zweryfikować wynik na podstawie wyrażenia regularnego, możesz zaznaczyć to pole wyboru, a następnie określić swoje Wyrażenie regularne w sekcji Zawartość. SoapUI stosuje się do wzorców wyrażeń regularnych określonych przez Oracle, na przykład, jeśli chcemy potwierdzić, że odpowiedź usługi książki zawiera „O’ Reilly „w odpowiedzi, możesz określić”.O ’ Reilly.”jako RegEx w sekcji Zawartość, jak pokazano poniżej:

tak więc, możemy zweryfikować istnienie ciągu znaków w odpowiedzi Usługi Webservice za pomocą twierdzenia Contains, i możemy tego użyć zarówno dla usług internetowych SOAP, jak i REST.

czego nie ma w SoapUI?

w przeciwieństwie do twierdzenia Contains, twierdzenie Not Contains wyszukuje nieistnienie łańcucha w wartości właściwości. Co więcej, to twierdzenie przejdzie, jeśli odpowiedź nie zawiera określonej wartości.

Załóżmy, że chcemy zweryfikować, że nie ma książki o tytule „Groovy Book”w odpowiedzi usługi księgarni, możemy użyć tego twierdzenia do zweryfikować odpowiedź API księgarni.

wykonajmy kroki wymienione poniżej, aby zweryfikować to samo za pomocą twierdzenia „nie zawiera” :

1. po pierwsze, przejdź do okna dialogowego Dodawanie twierdzenia i kliknij twierdzenie” nie zawiera „w kategorii twierdzenia „zawartość właściwości”, jak zaznaczono poniżej:

1. Po Drugie, kliknij przycisk” Dodaj”, a wyświetli się okno dialogowe „nie zawiera twierdzenia”, jak pokazano poniżej:

2. Po Trzecie, wpisz nazwę Łańcucha „Groo Book” w sekcji „Treść”. Jest to szukany ciąg, który chcesz zweryfikować, który nie istnieje w odpowiedzi Usługi WebService.

Uwaga: dwa pola wyboru (Ignoruj wielkość liter & Wyrażenie regularne) działają w ten sam sposób, jak w przypadku twierdzenia Contains.

1. Po czwarte, kliknięcie przycisku ” OK ” wykona assertion against the WebService response i pokaże wynik, jak pokazano poniżej:

1. tak więc, dopóki łańcuch nie jest obecny w odpowiedzi usługi docelowej, twierdzenie przejdzie.

co to jest XPath Match Assertion w SoapUI?

twierdzenie XPath Match pozwala na użycie wyrażenia XPath do wybrania zawartości z określonego węzła docelowej odpowiedzi i porównania jej z oczekiwaną wartością.

Załóżmy, że chcesz potwierdzić, że ISBN pierwszej książki obecnej w odpowiedzi na API księgarni nie jest równy null. Możemy szybko zweryfikować to samo za pomocą twierdzenia XPath.

wykonajmy kroki wymienione poniżej, aby zweryfikować to samo za pomocą twierdzenia „XPath Match” :

1. po pierwsze, przejdź do okna dialogowego Dodawanie twierdzenia. Następnie kliknij twierdzenie „XPath Match” w kategorii „Property Content”, jak zaznaczono poniżej:

1. Po Drugie, kliknij przycisk” Dodaj”, a wyświetli się okno dialogowe „XPath Match Configuration”, jak pokazano poniżej:

gdzie,

• Declare: kliknięcie tego przycisku automatycznie pobiera i wypełnia przestrzeń nazw. Jeśli jesteś pewien szczegółów przestrzeni nazw, możesz wpisać ją ręcznie, w przeciwnym razie po prostu kliknij przycisk” Zadeklaruj”, a wypełni on szczegóły przestrzeni nazw, jak pokazano poniżej:

  • przestrzeń nazw usługi SOAP zostanie wypełniona, jak pokazano poniżej:

• podobnie, przestrzeń nazw dla usługi REST zostanie wypełniona, jak pokazano poniżej:

po zadeklarowaniu przestrzeni nazw możemy określić XPATH żądanego węzła w sekcji wyrażenie XPath.

• możesz określić przykładową ścieżkę XPATH ” //ns1:BooksResult/NS1:Books/NS1:CustomBookModel/NS1:Isbn „dla usługi SOAP, jak pokazano poniżej:

podobnie, możesz określić przykładowy XPATH” //NS1:books//ns1:e/NS1:isbn ” dla usługi REST, jak pokazano poniżej:

zwróć uwagę na użycie przestrzeni nazw ns1 w obu przypadkach. Aby uzyskać dostęp do węzłów, użycie przestrzeni nazw jest obowiązkowe.

• Select from current: klikając ten przycisk, automatycznie wybierze wartość węzła, jak wspomniano powyżej w sekcji oczekiwany wynik, która jest isbn w powyższym przypadku. Dodatkowo wybierze wartość ISBN węzła jako „9781449325862”. Jeśli nie chcesz automatycznie wybrać wartości, klikając ten przycisk, możesz nawet ręcznie wpisać oczekiwany wynik.
• Test: klikając przycisk „Test”, możesz przetestować wynik, jeśli twierdzenie przejdzie, wyświetli się poniższy alert sukcesu:

lub jeśli twierdzenie się nie powiedzie, wyświetli błąd i wyświetli okno dialogowe, jak pokazano poniżej:

• opcjonalne pola wyboru: sekcja oczekiwany wynik zawiera również pola wyboru, które zapewniają dodatkową pomoc w sprawdzaniu poprawności twierdzenia. Poznajmy szczegóły tych pól wyboru:
• Allow Wildcard Checkbox: jeśli wartość, którą chcemy zweryfikować, zmienia się dynamicznie w odpowiedzi docelowej, możemy użyć symboli wieloznacznych do zweryfikować odpowiedź. Załóżmy, że jeśli weźmiemy pod uwagę, że isbn pierwszej książki zawsze kończy się na „862”, wówczas możemy użyć symbolu wieloznacznego *”862″, który potwierdzi, że isbn zawsze kończy się na „862”. Pojawi się w sekcji oczekiwany wynik jako:

• pole wyboru Ignoruj prefiks przestrzeni nazw: Jeśli chcemy zignorować przedrostek przestrzeni nazw podczas sprawdzania poprawności odpowiedzi, możemy to zrobić, zaznaczając to pole wyboru.
• Ignoruj Komentarze XML pole wyboru: jeśli chcemy zignorować komentarze w odpowiedzi, możemy to osiągnąć, zaznaczając to pole wyboru.
• po zapoznaniu się ze wszystkimi powyższymi opcjami kliknij przycisk Zapisz, aby zapisać twierdzenie. Przejdzie jako twierdzenie i otrzyma oczekiwany Isbn jako „9781449325862”. W związku z tym pokaże wynik próbki w następujący sposób:

Co To jest XQuery Match Assertion w SoapUI?

dopasowanie XQuery jest bardzo podobne do twierdzenia XPath, z tą tylko różnicą, że używa wyrażenia XQuery i porównuje je z oczekiwanym wynikiem.

rozważ scenariusz Załóżmy, że chcesz zweryfikować wszystkie „tytuły” książek dostępnych w odpowiedzi, niezależnie od kolejności, w jakiej istnieją. Możesz napisać prosty XQuery, a następnie jesteś gotowy do pracy.

wykonajmy kroki wymienione poniżej, aby zweryfikować to samo za pomocą twierdzenia „XQueryMatch” :

1. najpierw przejdź do okna dialogowego Dodaj twierdzenie. Następnie kliknij assertion „XQuery Match” w kategorii assertion „Property Content”, jak zaznaczono poniżej:

1. Po Drugie, kliknij przycisk” Dodaj”, a wyświetli się okno dialogowe” XQuery Match Configuration”, jak pokazano poniżej:

gdzie,

• wyrażenie XQuery: jest to wyrażenie XQuery, które należy określić, aby wyodrębnić wartość z odpowiedzi WebService. Na przykład, aby uzyskać tytuł wszystkich książek, możemy określić wyrażenie XQuery w następujący sposób:

<Result>{for$z in //*:CustomBookModelreturn (<Title>{data($z/*:Title)}</Title>)}</Result>

w powyższym fragmencie kodu:

• <Result> jest znacznikiem, w którym będzie przechowywany wynik oparty na odpowiedzi XQuery. Co więcej, może to być dowolny tag oparty na wyborze użytkownika.
• dodatkowo wykonujemy iterację odpowiedzi za pomocą pętli for, a $z jest dowolną zmienną, która otrzyma wartość z <CustomBookModel>.
• //. określa główny katalog CustomBookModel, można również nawigować za pomocą przestrzeni nazw, a następnie określając przestrzeń nazw zamiast**”//.”.***
• oprócz powyższego, funkcja „return” zwróci wartość znacznika <Title>.
• ponadto funkcja „data” Zwraca dane każdego znacznika title w znaczniku <CustomBookModel>.

2) Wybierz z bieżącego: Kliknij przycisk, aby wybrać bieżącą wartość z odpowiedzi zgodnie ze wspomnianym XQuery.

3) oczekiwany wynik: po kliknięciu przycisku” Wybierz z bieżącego ” zwróci wszystkie tytuły z odpowiedzi serwisu. Oczekiwany wynik można również określić ręcznie.

4) kliknięcie przycisku „Test” pokaże odpowiedź na sukces, jak pokazano poniżej:

1. kliknięcie przycisku ” OK ” pokaże prawidłowe wykonanie twierdzenia.

jakie są wspólne twierdzenia zgodności, statusu i standardowe w SoapUI?

podobnie jak wspólne twierdzenia dostarczane przez SoapUI w sekcji „Zawartość właściwości”, zawiera również pewne twierdzenia w kategorii” Zgodność, Status i Standard”, które są wspólne dla Soap i Rest Webservices. Zrozumiemy szczegóły wszystkich tych twierdzeń w następujących sekcjach:

jakie są twierdzenia kodów statusu HTTP dostarczane przez SoapUI?

jak wszyscy wiemy, kody statusu HTTP określają, czy żądanie HTTP zostało zakończone, czy nie. Wszystkie te kody odpowiedzi na ogół dzielą się na następujące kategorie:

1	1xx: informacje: te kody statusu reprezentują odbiór wniosku i jego przetwarzanie.
2	2xx: sukces: te kody statusu oznaczają, że akcja została pomyślnie odebrana, przetworzona i zaakceptowana.
3	3xx: przekierowanie: te kody statusu oznaczają, że wymagane jest dalsze działanie, aby zakończyć żądanie.
4	4xx: błąd Klienta: te kody stanu oznaczają, że żądanie zawiera nieprawidłową składnię lub coś jest nie tak z naszym żądaniem.
5	5xx: błąd serwera: te kody stanu oznaczają, że wystąpił błąd Po stronie serwera, co oznacza, że serwer nie spełnił prawidłowego żądania.

dla walidacji tych kodów statusu, SoapUI dostarcza kilka twierdzeń. Wyjaśnijmy szczegóły tych twierdzeń w następujących sekcjach:

Co To jest poprawne twierdzenie o kodach statusu HTTP w SoapUI?

to twierdzenie potwierdza, że kod odpowiedzi HTTP zwracany przez Webservice znajduje się na liście oczekiwanych kodów HTTP.

rozważmy scenariusz, że dla API księgarni chcemy sprawdzić, czy zwracany kod odpowiedzi to zawsze 200 lub 201. Możemy użyć twierdzenia „Valid HTTP Status Codes”, aby potwierdzić to samo.

wykonajmy kroki wymienione poniżej, aby zweryfikować to samo za pomocą twierdzenia „Valid HTTP Status Codes” :

1. przejdź do okna dialogowego Dodawanie twierdzeń i kliknij” poprawne kody statusu HTTP „w kategorii twierdzenia” Zgodność, Status i Standard”, jak zaznaczono poniżej:

1. kliknij przycisk” Dodaj”, a wyświetli się okno dialogowe „poprawna konfiguracja konfiguracji twierdzenia kodów statusu HTTP”, jak pokazano poniżej:

1. w sekcji „Określ kody” wpisz wartości 200, 201. Możesz określić pojedynczy kod lub listę kodów oddzielonych przecinkami. Kliknięcie przycisku ” OK ” potwierdzi kody statusu HTTP w stosunku do ostatniej odpowiedzi usługi.

Co to jest nieprawidłowe twierdzenie o kodach statusu HTTP w SoapUI?

w przeciwieństwie do twierdzenia „Valid HTTP status codes”, twierdzenie „Invalid HTTP status codes” potwierdza, że lista „Expected codes” nie zawiera kodu statusu HTTP zwracanego przez Webservice.

rozważmy scenariusz, w którym Dla API księgarni chcemy sprawdzić, czy zwracany kod odpowiedzi to nie 401. Możemy użyć assertion „Invalid HTTP Status Codes” aby potwierdzić to samo.

wykonajmy kroki wymienione poniżej, aby zweryfikować to samo za pomocą twierdzenia „Invalid HTTP Status Codes” :

1. przejdź do okna dialogowego dodawania twierdzeń i kliknij twierdzenie „nieprawidłowe kody statusu HTTP” w kategorii twierdzenia „Zgodność, Status i Standard”, jak zaznaczono poniżej:

1. kliknij przycisk” Dodaj”, a wyświetli się okno dialogowe „Invalid HTTP status codes Assertion Configuration”, jak pokazano poniżej:

1. w sekcji” Określ kody ” wpisz wartości 401. Możesz określić pojedynczy kod lub listę kodów oddzielonych przecinkami. Kliknięcie przycisku ” OK ” potwierdzi nieistnienie kodów statusu HTTP w stosunku do ostatniej odpowiedzi usługi.

uwaga: możemy zastosować te twierdzenia zarówno do punktów końcowych SOAP, jak i REST.

jakie są twierdzenia zgodności schematu w SoapUI?

oprócz kodów statusu, w SoapUI, możemy również zweryfikować wiadomość odpowiedzi zgodnie z definicją w WSDL (SOAP) lub WADL(REST) testowanej usługi docelowej.

zastanów się nad scenariuszem, w którym chcemy szybko sprawdzić, czy odpowiedź SOAP, którą otrzymujemy, jest zgodna z WSDL, czy nie?

wykonajmy kroki wymienione poniżej, aby zweryfikować to samo za pomocą twierdzenia „Zgodność schematu” :

1. przejdź do okna dialogowego Dodawanie twierdzeń i kliknij” Zgodność schematu „w kategorii” Zgodność, Status i Standard”, jak zaznaczono poniżej:

1. kliknij przycisk „Dodaj”, a wyświetli się okno dialogowe „Konfiguracja zgodności schematu”, jak pokazano poniżej:

2. w oknie dialogowym Konfiguracja automatycznie zapełnia WSDL, który stworzył projekt, ale jeśli chcesz określić inne WSDL, możesz go również zaktualizować. Kliknij OK, aby kontynuować.

1. jeśli odpowiedź jest zgodna ze wspomnianym schematem, zobaczysz odpowiedź sukcesu, jak pokazano powyżej. Błąd pojawi się, gdy ostatnia odpowiedź nie jest zgodna ze schematem WSDL.

Uwaga: Podobnie, możesz zweryfikować odpowiedź usługi REST przeciwko określonemu WADL.

jakie są wspólne twierdzenia SLA w SoapUI?

jak wszyscy wiemy, Umowa o poziomie usług(SLA) jest ogólnie określana jako umowa między usługodawcą a klientem. Umowę można sklasyfikować według różnych uzgodnionych cech, takich jak dostępność, jakość, czas reakcji itp. SoapUI zapewnia funkcjonalność do sprawdzania czasu reakcji określonej usługi.

rozważmy hipotetyczny scenariusz, że uzgodniony czas reakcji dla Serwisu Internetowego księgarni jest krótszy niż 4 sekundy. To samo możemy zweryfikować w SoapUI używając kategorii twierdzeń „SLA”.

wykonajmy kroki wymienione poniżej, aby zweryfikować to samo za pomocą twierdzenia „Response SLA” :

1. przejdź do okna dialogowego Dodawanie twierdzeń i kliknij twierdzenie” Response SLA „w kategorii twierdzenia” SLA”, jak zaznaczono poniżej:

1. kliknij przycisk” Dodaj”, a wyświetli się okno dialogowe „Konfiguracja twierdzenia SLA odpowiedzi”, jak pokazano poniżej:

1. Określ maksymalny czas (w ms), w którym usługa oczekuje zwrotu odpowiedzi. Dla naszego scenariusza określiliśmy 4000 ms. kliknij przycisk OK, aby dodać twierdzenie. Pokaże wynik testu, jak pokazano poniżej:

1. jak widać na powyższym zrzucie ekranu, ponieważ czas reakcji usługi wynosił 1374 ms, więc był pod wspomnianym SLA 4000 ms i zaowocował pomyślnym twierdzeniem.

kluczowe wnioski

• SoapUI zapewnia szeroki zakres twierdzeń, które mogą być stosowane zarówno do usług internetowych SOAP, jak i REST.
• dodatkowo, kilka typowych twierdzeń to Contain, Not Contain, XPath i XQuery Match, które są używane do walidacji odpowiedzi zawartości Serwisu.
• co Więcej, inny zestaw typowych twierdzeń dostarczanych przez SoapUI jest używany do walidacji kodów statusu HTTP i schematu odpowiedzi WebServices.
• ponadto SoapUI zapewnia również twierdzenie SLA, które można wykorzystać do walidacji czasu reakcji zarówno usług SOAP, jak i REST.

przejdźmy do następnego artykułu, gdzie będziemy głębiej zanurkować dalej, aby zrozumieć, w jaki sposób możemy zaimplementować niektóre zaawansowane twierdzenia za pomocą „script Assertions” w SoapUI.