Твърдения в SoapUIСкриптове, XQuery, XPath типове
⚡ Умно обобщение
Твърдения в SoapUI са контролните точки, които решават дали отговорът на уеб услугата е правилен, превръщайки заявка, която просто се изпълнява, в тест, който действително преминава или не преминава проверка на реално, проверимо съдържание.

Какво е твърдение?
Твърдението означава акт на потвърждаване или заявяване на нещо. Може също да се тълкува като контролна точка или точка за валидиране.
След като заявка бъде изпратена до уеб сървър, се получава отговор. Трябва да проверим дали отговорът съдържа очакваните данни. За да валидираме отговора, трябва да използваме твърдения (assertions). Без твърдение, стъпката на тестване само доказва, че услугата е отговорила, а не че е отговорила правилно, поради което всеки API тест трябва да носи поне един.
Видове твърдения
Има различни начини за изразяване на отговор; ние обаче ще се съсредоточим върху най-често използваните SoapUI типове твърдения при валидиране на отговор. По-долу са категориите, които са налични във версията с отворен код на SoapUI.
- Съдържание на собствеността
- Стандарт за състояние на съответствие
- Сценарий
- SLA
- JMS
- Охрана
Диалоговият прозорец групира всяко твърдение в тези категории, както е показано на екранната снимка по-долу.

Освен изброените по-горе, Pro версията има и вградено JDBC твърдение, чрез което можем да проверим дали уеб услугата е актуализирала базата данни правилно.
Бележка към версията: ток SoapUI документацията също така изброява a JDBC категория (JDBC статус и JDBC таймаут) наред с категориите по-горе и a Съдържание на съобщението твърдение в съдържанието на свойствата за по-богато XML сравнение. Търговското издание, наричано тук „Pro“, вече се продава като ReadyAPI от SmartBear, така че етикетите на менютата в по-новите компилации може да се четат различно, докато поведението на твърдението остава същото.
Съдържа твърдение
Търси съществуването на посочения низ. Той също така поддържа регулярен израз.
Ще продължим със същия пример от предишния урок с WSDL заявка като http://www.dneonline.com/calculator.asmxАко все още не сте изградили този проект, работете върху него създаване на проект, тестов набор и тестов случай на първо място.
Стъпка 1: По подразбиране няма твърдения.
- Броят на твърденията се показва в раздела Твърдения.
- За да добавите ново твърдение, щракнете върху бутона „Добавяне на ново твърдение“.
Стъпка 2: Сега,
- Изберете категорията на твърдението.
- Изберете Тип твърдение.
- Щракнете върху "Добавяне"
Стъпка 3: Нека проверим дали низът „46“ съществува в отговора. Щракнете върху „OK“.
Забележка: Можем също да игнорираме малки и големи букви и да добавим регулярен израз.
Стъпка 4: След добавянето му, незабавно се изпълнява твърдение и се показва дали е ВАЛИДНО или НЕВАЛИДНО.
Стъпка 5: Сега да кажем, че променяме съдържанието на „Съдържа твърдение в SoapUI' до '47' и вижте какво ще се случи.
Стъпка 6: Твърдението се изпълнява и резултатът се предава на потребителя. Тъй като нямаме низа '47' в отговора, твърдението е неуспешно.
Не съдържа твърдение
Неговият еквивалент работи по обратния начин. Търси несъществуване на посочения низ. Също така поддържа регулярни изрази.
Стъпка 1: След като кликнете върху бутона „добавяне на нови твърдения“,
- Изберете категорията на твърдението.
- Изберете типа твърдение – в този случай „НЕ съдържа“
- Щракнете върху "Добавяне"
Стъпка 2: Нека проверим дали низът „intA“ съществува в отговора. Въведете низа „FromCurrency“ и щракнете върху „OK“.
Стъпка 3: Веднага щом се добави твърдение, то се изпълнява и показва резултата. Досега добавихме две твърдения, следователно и двете твърдения се изпълняват и показват резултата.
Стъпка 4: Сега нека променим съдържанието на „Not Contains Assertion“ и да видим какво ще се случи. Ще проверим за несъществуване на низа „AddResult“.
Стъпка 5: Низът „AddResult“ действително присъства в отговора, следователно твърдението „NOT Contains“ ще се провали, както е показано по-долу.
Твърдение за съответствие на XPath
Съпоставянето на низове е неточно, така че следващото твърдение е насочено към единичен възел. Използва XPath израз, за да избере целевия възел и неговите стойности. XPath, е XML език за заявки за избиране на възли от XML документ.
Стъпка 1: След като кликнете върху бутона „Добавяне на нови твърдения“,
- Изберете категорията на твърдението.
- Изберете типа твърдение – в този случай „XPath Match“
- Щракнете върху "Добавяне"
Стъпка 2: Отваря се прозорецът за добавяне на XPath.
Преди да добавите SoapUI XPath, трябва да декларираме пространството от имена. XML пространството от имена е колекция от имена, идентифицирани чрез URI (Uniform Resource Identifier) препратка, които се използват в XML документи като имена на елементи и атрибути. Същото се използва и в SoapUI XPath твърдение.
За да декларираме XML пространство от имена, просто трябва да кликнем върху бутона „Деклариране“, който ще свърши работата вместо нас, в противен случай можем и ръчно да декларираме пространство от имена сами.
След декларирането на пространството от имена, трябва да се обърнем към XPath, използвайки създаденото пространство от имена.
След като щракнете върху бутона „Деклариране“, ще се появят две пространства от имена, тъй като имаме два URI адреса. Едното от тях е схемата. URL а другият съответства на действителната уеб услуга URLТрябва да използваме действителното пространство от имена, където се намира уеб услугата, а НЕ пространството от имена на схемата, когато се позоваваме на XPath. Декларираните редове се появяват в горната част на XPath полето, както е показано по-долу.
декларирайте namespace soap='http://schemas.xmlsoap.org/soap/envelope/';
декларирайте пространство от имена ns1='http://tempuri.org/';
Стъпка 3: Сега трябва да въведем XPath на XML възела, който трябва да валидираме.
//ns1:AddResult Дава ни стойността на възела, затворен между и и ns1 съответства на декларираното пространство от имена, което сочи към „http://tempuri.org/“
След като въведем XML, трябва да щракнем върху „Избор от текущия“, така че стойността от текущия отговор да бъде взета за сравнение в бъдеще.
Стъпка 4: Досега,
- След като декларираме пространствата от имена, въведохме XPath на XML възел, който трябва да валидираме.
- Трябва да щракнете върху „Избор от текуща“, за да направим текущата стойност като очаквана стойност.
- Текущата стойност се показва на потребителя, която можем да променим, ако е необходимо.
- Щракнете върху „Запазване“.
Стъпка 5: Добавеното твърдение в SoapUI ще се покаже, както е показано по-долу.
Скриптови твърдения
Тази техника за твърдения е най-широко използваната, тъй като е изключително трудно да се управляват и поддържат стотици твърдения.
SoapUI използва или Groovy Скриптиране или JavaСценарий за скриптиране на твърдения. Техниката на скриптиране е възприета за разработванеping рамка за тестване на SOAP. Твърденията за скриптове се използват при следните обстоятелства.
- Скриптирането позволява на потребителя да извършва някои операции преди и след изпълнението на тестов случай, използвайки съответно методите set up и tear down. Set up е процедура, която се изпълнява преди изпълнението на определен метод (пример - създаване и инициализация на обекти), докато tear down е процедура, която се изпълнява след изпълнението на метода (напр.: унищожаване на обекти и почистване). Тази функция не е налична в други типове твърдения и може да се осъществи само чрез кодиране.
- Позволява на потребителите да отварят/затварят проект, да инициализират или почистят настройките, свързани с проекта, както и да работят с променливи на средата, което е много полезно по време на писане на скриптове.
- Помага ни при утвърждаването на динамично съдържание на отговора.
- Скриптовите твърдения се използват за създаване на потребителски дефинирани твърдения, които НЕ са предварително дефинирани от SoapUI.
За демонстриране на твърдение на скрипт в SoapUI, ще използваме WSDL калкулатора, тестовия случай „Добавяне“, който създадохме по-рано.
Стъпка 1: Стъпките за добавяне на groovy скрипт са същите като тези за други твърдения, с изключение на това, че твърдението не е предварително дефинирано. Вместо това е потребителски дефинирано твърдение, което предлага по-голяма гъвкавост от вградените.
Изберете тестовата стъпка, спрямо която трябва да се добави твърдението.
Щракнете върху бутона „Добавяне на твърдение“, както е показано по-долу.
Стъпка 2: Сега изберете категорията „Твърдение“.
- В този случай това е скрипт.
- Изберете SoapUI Твърдение на скрипт и няма свързани с него подтипове.
- Кликнете върху „Добавяне“.
Стъпка 3: Отваря се диалоговият прозорец за скриптове, където потребителят ще може да напише дефиниран от потребителя скрипт, за да валидира XML файла на отговора.
Стъпка 4: Сега нека напишем страхотен скрипт за валидиране на процента на конверсия. Скриптът е приложен по-долу с вградени коментари. Препоръчително е да имате познания за Java Сценарий или Groovy Скрипт, преди да се опитате да напишете свой собствен скрипт.
//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"}
- Щракнете върху бутона „Изпълнение“, за да задействате изпълнението.
- Резултатът от скрипта се показва в прозореца Изход. Той е отпечатал както стойността на преобразуването, така и крайния резултат (успешен или неуспешен)
- Показва се информацията, че „Script Assertion Passed“. Натиснете OK.
Забележка: Последният изскачащ прозорец с информация винаги ще се показва със съобщението „Утвърждението на скрипта е преминало“, стига скриптът да е синтактично правилен. Няма връзка с вашето твърдение в сценария.
натиснете ОК
Стъпка 5: Сега разделът „твърдения“ показва всички твърдения, които сме добавили за този тестов набор, със статуса на всяко едно от тях.
Стъпка 6: Сега
- Изберете пакета за тестване от дървото на навигатора
- Щракнете върху бутона „Изпълни“.
- Резултатите ще бъдат показани за целия набор от тестове.
Твърдение за съвпадение в XQuery
Той използва XQuery израз, за да избере съдържание от целевото свойство. Нуждаем се от много по-голям XML отговор, за да разберем по-добре XQuery твърдението в SoapUIНека импортираме още един WSDL, както е показано по-долу: http://www.webservicex.net/medicareSupplier.asmx?WSDL
Забележка: Публичните демонстрационни крайни точки на webservicex.net, използвани в това ръководство, вече не са надеждно достъпни, така че екранните снимки на заявки и отговори по-долу се запазват като референтен пример. Всеки WSDL, който връща повтарящ се набор от възли, ще упражни XQuery твърдението по абсолютно същия начин.
Стъпка 1: Щракнете с десния бутон върху съществуващия проект и изберете „Добавяне на WSDL“.
Стъпка 2: Отваря се диалоговият прозорец „Добавяне на WSDL“. Оставете другите опции по подразбиране и щракнете върху бутона „OK“.
Стъпка 3: Всички операции са изброени, както е показано по-долу.
Стъпка 4: Сега нека добавим Тестов случай в рамките на същия тестов пакет, за който създадохме Тестване валутен конвертор.
Стъпка 5: Въведете името на тестовия случай и щракнете върху бутона „OK“
Стъпка 6: Тестовият случай се създава, както е показано по-долу.
Стъпка 7: Добавете нова тестова стъпка от тип „Заявка за тест на SOAP“, както е показано по-долу.
Стъпка 8: Въведете името на тестовата стъпка. Да кажем – Supplier_by_City, което би било по-смислено. Кликнете върху „OK“.
Стъпка 9: Изберете Operaция, която бихме искали да валидираме. В този случай това е „MedicareSupplierSoap -> GetSupplierByCity“. Кликнете върху „OK“.
Стъпка 10: Въведете името на тестовия случай и щракнете върху „OK“.
Стъпка 11: XML структурата на заявката ще се покаже, както е показано по-долу.
Стъпка 12: Сега нека намерим цялата информация за доставчиците за град „Ню Йорк“.
За да направите това, добавете следните редове към вашия код.
<GetSupplierByCity xmlns="http://www.webservicex.net/"> <City>New York</City> </GetSupplierByCity>
WSDL по-долу URL – http://www.webservicex.net/medicareSupplier.asmx?op=GetSupplierByCity
Стъпка 13: След изпълнение на теста получаваме следния отговор
Стъпка 14: Да кажем, че трябва да валидираме всички номера на доставчици. Не можем да използваме XPath Assertion, тъй като се нуждаем от стотици XPath Assertion. Следователно използването на XQuery е неизбежно в този случай.
XQuery Assertion ни помага да валидираме група от XML отговори, които са повтарящи се по природа.
Стъпка 15: Сега кликнете върху „Добавяне на твърдение“,
- Изберете „Категория на твърдението“ – в този случай съдържание на собственост.
- Изберете типа твърдение като „XQuery твърдение“
- Кликнете върху „Добавяне“.
Стъпка 16: Подобно на XPath Assertion, трябва да декларираме пространството от имена.
- Кликнете върху бутона „Деклариране“, за да разрешите автоматично SoapUI за да декларирате пространството от имена. След щракване върху бутона за деклариране, на потребителя ще се покаже „изскачащ прозорец“ със съобщението „декларирайте пространството от имена от схема вместо това“. Щракнете върху „Да“, за да продължите, както е показано по-долу.
- За да извлечем целия номер на доставчик, трябва да напишем XPath заявка и ще я поставим в < SupplierNumber> и Етикети.
- Щракнете върху „Избор от текущия“, който ще се изпълни от текущия отговор.
- След като щракнете върху „Избери от текущите“, ще бъдат изброени всички номера на доставчици.
- Щракнете върху „Запазване“.
Забележка: След натискане на бутона „Деклариране“ може да се окажете с различни URLкато декларация за пространство от имена, обаче, действителното пространство от имена на местоположението на уеб услугата е това, което би се вземало предвид при кодирането.
Готовият XQuery израз, с декларациите на неговите пространства от имена, изглежда така.
// 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)} }
Стъпка 17: XQuery твърдението се изпълнява и показва крайния резултат в панела „Твърдение“, както е показано по-долу. Сега успешно добавихме XQuery твърдение, с което валидирахме цялата информация за номера на доставчика. Същата ще се сравнява с действителните стойности всеки път, когато заявката се изпраща към уеб сървъра.
Забележка: Действителните стойности няма да бъдат показани. Ако всички действителни стойности са същите като тези на очакваните стойности, тогава се показва VALID, в противен случай ще се покаже „Неуспешно“.
Кога да използвате вградено твърдение?
След като са обхванати както опциите за кликване с посочване, така и скриптовите, практическият въпрос е кой да изберете.
- Когато отговорът е кратък, така че да може да бъде валидиран с помощта на едно от тези вградени твърдения.
- Можем също да използваме Inbuilt Assertion, ако отговорът, изпратен от уеб сървъра, винаги е статичен по природа. Ако е динамичен, няма да можем да го потвърдим с помощта на вградени твърдения.
- Когато използването на вградени твърдения като твърдения за изчакване и твърдения за сигурност стане неизбежно.
- Вградените твърдения се държат доста добре за еднократна употреба, когато тестовете не трябва да се повтарят.
Опции за твърдения
Създадените твърдения могат да се контролират най-добре с помощта на контролния панел, който е маркиран по-долу.
Създадените твърдения позволяват на тестерите да конфигурират следните неща от кутията с инструменти за твърдения.
| Опция | Descriptйон |
| Избраното твърдение се придвижва нагоре в реда. | |
| Избраното твърдение се придвижва надолу по реда. | |
| Премахва избраното твърдение | |
| Преконфигурирайте/редактирайте избраното твърдение. |
По-долу са функциите, достъпни ексклузивно в Pro версията на SoapUI, сега се доставя като ReadyAPIPro версията ни помага и да групираме твърдения, така че да можем да добавим още един слой валидиране към създадените твърдения.
- И: Всички твърдения се оценяват като ВАЛИДНИ, което ще доведе до групово условие PASSED.
- ИЛИ: Поне едно от твърденията в групата трябва да е ВАЛИДНО, за да се утвърди условието за PASSED в групата.
- Pro версия също позволява Клониране на твърденияТази опция позволява на тестерите да разрешат копиране на твърдение в различна тестова стъпка в същия или различен проект.
- Деактивиране/Активиране на твърдения: Тази опция позволява всяко групирано или негрупирано твърдение да бъде деактивирано или активирано. Ако дадено твърдение е деактивирано, то е сиво и когато се изпълни тестов случай, деактивираните твърдения няма да бъдат изпълнени.
- Разгрупиране на твърдения: Всички групирани твърдения могат да бъдат разгрупирани, ако тестерите решат да го направят.
Пълен списък с методи, налични в различни типове твърдения
Таблицата по-долу събира всяко твърдение, обсъдено по-горе, групирано по категорията, в която се показва в диалоговия прозорец „Добавяне на твърдение“.
| Утвърждаващ механизъм | Descriptйон |
| СЪДЪРЖАНИЕ НА ИМОТА | |
| Съдържа | Търси съществуването на посочения низ. Той също така поддържа регулярен израз. |
| Не съдържа | Търси несъществуването на посочения низ. Той също така поддържа регулярен израз. |
| Съвпадение на XPath | Използва XPath израз за избор на целевия възел и неговите стойности. |
| Съвпадение на XQuery | Използва XQuery израз за избор на съдържание от целевото свойство. |
| Съответствие, статус, стандарти | |
| HTTP Изтегляне на целия ресурс | Валидира HTML документа след изтегляне и се отнася добре за всяко свойство, съдържащо HTML. |
| Невалиден HTTP статус Codes | Проверява дали HTML отговорът съдържа код на състояние, който не е в списъка с дефинирани кодове. |
| Не е SOAP грешка | Проверява дали последното получено съобщение не е SOAP грешка. Много очевидно е, че е приложимо само за SOAP Test Steps. |
| Съответствие на схемата | Проверява дали последното получено съобщение е съвместимо с дефиницията на стандартната схема на WSDL или WADL. Поддържа се добре за SOAP и REST тестови стъпки. |
| SOAP грешка | Проверява дали последното получено съобщение е SOAP грешка. Това е обратното на твърденията за грешка „НЕ SOAP“. |
| SOAP отговор | Проверява дали последният получен отговор е валиден SOAP отговор и е валиден само за SOAP Test Request Steps. |
| Валиден HTTP статус Codes | Проверява дали HTML отговорът съдържа код за състояние, който е в списъка с дефинирани кодове. Това е обратното на „Невалиден HTTP статус“. CodeТвърдение. |
| WS-заявка за адресиране | Проверява дали последната получена заявка съдържа подходящи заглавки за WS-адресиране. |
| WS-адресиращ отговор | Проверява дали последният получен отговор съдържа подходящи заглавки за WS-адресиране. |
| WS-Състояние на сигурността | Проверява дали последното получено съобщение съдържа валидни заглавки на WS-Security и е валидно само за SOAP заявки. |
| Сценарий | |
| Твърдение на скрипта | Позволява на потребителите да изпълняват персонализиран скрипт за извършване на дефинирани от потребителя проверки. |
| SLA | |
| SLA за отговор | Потвърждава дали времето за отговор на последния получен отговор е в рамките на дефинирания лимит. |
| JMS | |
| Състояние на JMS | Проверява дали JMS заявката на тестовата стъпка е изпълнена успешно и е валидна за тестови стъпки с JMS крайна точка. |
| Време за изчакване на JMS | Проверява дали отговорът на JMS на тестова стъпка не е отнел повече от определената продължителност. |
| Охрана | |
| Излагане на чувствителна информация | Проверява дали съобщението за отговор не разкрива поверителна информация за целевата система. Можем да използваме това твърдение за REST, SOAP и HTTP тестови стъпки. |
ИЗТЕГЛЕТЕ ПРОЕКТА SOAPUI, СЪДЪРЖАЩ ГОРНИТЕ ТВЪРДЕНИЯ
Често срещани грешки и отстраняване на неизправности
Повечето неуспешни твърдения tracВръщаме се към малък набор от грешки, така че ги проверете, преди да пренапишете израз.
- Използвайте правилното пространство от имена. Пространството от имена трябва да бъде URL където се намира уеб услугата.
- Ако се възникне грешка по време на разработкатаping скриптово твърдение, използвайте 'log.info', за да отпечатате съдържанието на променливите.
- Ако не сте получили желания изход, проверете дали в заявката е подаден валиден вход.
Например, във валутен конвертор, ако въведете „intA“ като „x“, което не е цяло число, изходът ще изведе код за грешка „SOAP-Client“, което означава, че проблемът е с параметъра, който се предава от страна на клиента. Заявката, носеща невалидната стойност, се показва първа.
Отговорът връща кода на грешката вместо резултат, както е показано по-долу.
Уверете се, че използвате правилния синтаксис, когато използвате XPath и XQuery твърдение. НЕ трябва да използвате dot(.) вместо colon(:), когато използвате горното твърдение. Синтаксисът е //namespace:Tagname, а НЕ //namespace.tagname. По този начин може да получите съобщение „НЯМА съвпадение в текущия отговор“, въпреки че името на тага е правилно.














































