Твърдения в SoapUIСкриптове, XQuery, XPath типове

⚡ Умно обобщение

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

  • 🔘 Категории: Съдържание на свойства, съответствие/състояние/стандарти, скрипт, SLA, JMS и сигурност.
  • ☑️ Съдържа: Потвърждава съществуването на низ в отговора, с поддръжка на регулярни изрази.
  • Не съдържа: Потвърждава липсата на низ, полезно за маркери за грешки и изтичащи полета.
  • 🧪 Съвпадение на XPath: Първо декларирайте пространството от имена, след това насочете се към един възел и сравнете неговата стойност.
  • 🛠️ Съвпадение на XQuery: Валидира повтарящи се набори от възли, които иначе биха се нуждаели от стотици XPath проверки.
  • 📊 скрипт: Groovy Твърденията обработват динамични отговори и логика за настройка или демонтаж.
  • 🔍 Отстраняване на неизправности: Грешното пространство от имена и синтаксисът с точка вместо двоеточие причиняват повечето неуспехи.

Твърдения в SoapUI

Какво е твърдение?

Твърдението означава акт на потвърждаване или заявяване на нещо. Може също да се тълкува като контролна точка или точка за валидиране.

След като заявка бъде изпратена до уеб сървър, се получава отговор. Трябва да проверим дали отговорът съдържа очакваните данни. За да валидираме отговора, трябва да използваме твърдения (assertions). Без твърдение, стъпката на тестване само доказва, че услугата е отговорила, а не че е отговорила правилно, поради което всеки API тест трябва да носи поне един.

Видове твърдения

Има различни начини за изразяване на отговор; ние обаче ще се съсредоточим върху най-често използваните SoapUI типове твърдения при валидиране на отговор. По-долу са категориите, които са налични във версията с отворен код на SoapUI.

  1. Съдържание на собствеността
  2. Стандарт за състояние на съответствие
  3. Сценарий
  4. SLA
  5. JMS
  6. Охрана

Диалоговият прозорец групира всяко твърдение в тези категории, както е показано на екранната снимка по-долу.

Категории твърдения, изброени в SoapUI Диалогов прозорец за добавяне на твърдение
Видове твърдения в SoapUI

Освен изброените по-горе, Pro версията има и вградено JDBC твърдение, чрез което можем да проверим дали уеб услугата е актуализирала базата данни правилно.

Бележка към версията: ток SoapUI документацията също така изброява a JDBC категория (JDBC статус и JDBC таймаут) наред с категориите по-горе и a Съдържание на съобщението твърдение в съдържанието на свойствата за по-богато XML сравнение. Търговското издание, наричано тук „Pro“, вече се продава като ReadyAPI от SmartBear, така че етикетите на менютата в по-новите компилации може да се четат различно, докато поведението на твърдението остава същото.

Съдържа твърдение

Търси съществуването на посочения низ. Той също така поддържа регулярен израз.

Ще продължим със същия пример от предишния урок с WSDL заявка като http://www.dneonline.com/calculator.asmxАко все още не сте изградили този проект, работете върху него създаване на проект, тестов набор и тестов случай на първо място.

Стъпка 1: По подразбиране няма твърдения.

  1. Броят на твърденията се показва в раздела Твърдения.
  2. За да добавите ново твърдение, щракнете върху бутона „Добавяне на ново твърдение“.

SoapUI Разделът „Твърдения“, който не показва твърдения, и бутонът „Добавяне на ново твърдение“

Стъпка 2: Сега,

  1. Изберете категорията на твърдението.
  2. Изберете Тип твърдение.
  3. Щракнете върху "Добавяне"

Добавяне на диалогов прозорец за твърдение с избрана категория и тип на твърдението

Стъпка 3: Нека проверим дали низът „46“ съществува в отговора. Щракнете върху „OK“.

Забележка: Можем също да игнорираме малки и големи букви и да добавим регулярен израз.

Съдържа диалогов прозорец за конфигуриране на твърдение с въведена стойност 46

Стъпка 4: След добавянето му, незабавно се изпълнява твърдение и се показва дали е ВАЛИДНО или НЕВАЛИДНО.

Разделът „Твърдения“, отчитащ твърдението „Съдържа“ като ВАЛИДНО

Стъпка 5: Сега да кажем, че променяме съдържанието на „Съдържа твърдение в SoapUI' до '47' и вижте какво ще се случи.

Редактиране на съдържанието на твърдението „Съдържа“ от 46 на 47

Стъпка 6: Твърдението се изпълнява и резултатът се предава на потребителя. Тъй като нямаме низа '47' в отговора, твърдението е неуспешно.

Разделът „Твърдения“ отчита твърдението „Съдържа“ като неуспешно

Не съдържа твърдение

Неговият еквивалент работи по обратния начин. Търси несъществуване на посочения низ. Също така поддържа регулярни изрази.

Стъпка 1: След като кликнете върху бутона „добавяне на нови твърдения“,

  1. Изберете категорията на твърдението.
  2. Изберете типа твърдение – в този случай „НЕ съдържа“
  3. Щракнете върху "Добавяне"

Диалогов прозорец за добавяне на твърдение с избрано „НЕ съдържа“

Стъпка 2: Нека проверим дали низът „intA“ съществува в отговора. Въведете низа „FromCurrency“ и щракнете върху „OK“.

Диалогов прозорец „Не съдържа твърдение“ с въведения низ „FromCurrency“

Стъпка 3: Веднага щом се добави твърдение, то се изпълнява и показва резултата. Досега добавихме две твърдения, следователно и двете твърдения се изпълняват и показват резултата.

Раздел „Твърдения“, в който са изброени резултатите „Съдържа“ и „Не съдържа“

Стъпка 4: Сега нека променим съдържанието на „Not Contains Assertion“ и да видим какво ще се случи. Ще проверим за несъществуване на низа „AddResult“.

Проверка на диалоговия прозорец „Не съдържа твърдение“ за токена AddResult

Стъпка 5: Низът „AddResult“ действително присъства в отговора, следователно твърдението „NOT Contains“ ще се провали, както е показано по-долу.

Твърдението „Не съдържа“ е неуспешно, защото е наличен AddResult

Твърдение за съответствие на XPath

Съпоставянето на низове е неточно, така че следващото твърдение е насочено към единичен възел. Използва XPath израз, за ​​да избере целевия възел и неговите стойности. XPath, е XML език за заявки за избиране на възли от XML документ.

Стъпка 1: След като кликнете върху бутона „Добавяне на нови твърдения“,

  1. Изберете категорията на твърдението.
  2. Изберете типа твърдение – в този случай „XPath Match“
  3. Щракнете върху "Добавяне"

Диалогов прозорец за добавяне на твърдение с избрано съвпадение на XPath

Стъпка 2: Отваря се прозорецът за добавяне на XPath.

Преди да добавите SoapUI XPath, трябва да декларираме пространството от имена. XML пространството от имена е колекция от имена, идентифицирани чрез URI (Uniform Resource Identifier) ​​препратка, които се използват в XML документи като имена на елементи и атрибути. Същото се използва и в SoapUI XPath твърдение.

За да декларираме XML пространство от имена, просто трябва да кликнем върху бутона „Деклариране“, който ще свърши работата вместо нас, в противен случай можем и ръчно да декларираме пространство от имена сами.

След декларирането на пространството от имена, трябва да се обърнем към XPath, използвайки създаденото пространство от имена.

След като щракнете върху бутона „Деклариране“, ще се появят две пространства от имена, тъй като имаме два URI адреса. Едното от тях е схемата. URL а другият съответства на действителната уеб услуга URLТрябва да използваме действителното пространство от имена, където се намира уеб услугата, а НЕ пространството от имена на схемата, когато се позоваваме на XPath. Декларираните редове се появяват в горната част на XPath полето, както е показано по-долу.

Декларирани пространства от имена SOAP и ns1 в прозореца на твърдението XPath

декларирайте namespace soap='http://schemas.xmlsoap.org/soap/envelope/';

декларирайте пространство от имена ns1='http://tempuri.org/';

Прозорец за XPath твърдение веднага след щракване върху „Декларирай“

Стъпка 3: Сега трябва да въведем XPath на XML възела, който трябва да валидираме.

//ns1:AddResult Дава ни стойността на възела, затворен между и и ns1 съответства на декларираното пространство от имена, което сочи към „http://tempuri.org/“

След като въведем XML, трябва да щракнем върху „Избор от текущия“, така че стойността от текущия отговор да бъде взета за сравнение в бъдеще.

XPath израз, въведен с маркирано „Избери от текущия“

Стъпка 4: Досега,

  1. След като декларираме пространствата от имена, въведохме XPath на XML възел, който трябва да валидираме.
  2. Трябва да щракнете върху „Избор от текуща“, за да направим текущата стойност като очаквана стойност.
  3. Текущата стойност се показва на потребителя, която можем да променим, ако е необходимо.
  4. Щракнете върху „Запазване“.

Конфигурация на XPath Match, показваща очакваната стойност и бутона „Запазване“

Стъпка 5: Добавеното твърдение в SoapUI ще се покаже, както е показано по-долу.

Разделът „Твърдения“, показващ добавеното твърдение за съвпадение на XPath

Скриптови твърдения

Тази техника за твърдения е най-широко използваната, тъй като е изключително трудно да се управляват и поддържат стотици твърдения.

SoapUI използва или Groovy Скриптиране или JavaСценарий за скриптиране на твърдения. Техниката на скриптиране е възприета за разработванеping рамка за тестване на SOAP. Твърденията за скриптове се използват при следните обстоятелства.

  • Скриптирането позволява на потребителя да извършва някои операции преди и след изпълнението на тестов случай, използвайки съответно методите set up и tear down. Set up е процедура, която се изпълнява преди изпълнението на определен метод (пример - създаване и инициализация на обекти), докато tear down е процедура, която се изпълнява след изпълнението на метода (напр.: унищожаване на обекти и почистване). Тази функция не е налична в други типове твърдения и може да се осъществи само чрез кодиране.
  • Позволява на потребителите да отварят/затварят проект, да инициализират или почистят настройките, свързани с проекта, както и да работят с променливи на средата, което е много полезно по време на писане на скриптове.
  • Помага ни при утвърждаването на динамично съдържание на отговора.
  • Скриптовите твърдения се използват за създаване на потребителски дефинирани твърдения, които НЕ са предварително дефинирани от SoapUI.

За демонстриране на твърдение на скрипт в SoapUI, ще използваме WSDL калкулатора, тестовия случай „Добавяне“, който създадохме по-рано.

Стъпка 1: Стъпките за добавяне на groovy скрипт са същите като тези за други твърдения, с изключение на това, че твърдението не е предварително дефинирано. Вместо това е потребителски дефинирано твърдение, което предлага по-голяма гъвкавост от вградените.

Изберете тестовата стъпка, спрямо която трябва да се добави твърдението.

Стъпка на теста, избрана в SoapUI навигатор преди добавяне на твърдение

Щракнете върху бутона „Добавяне на твърдение“, както е показано по-долу.

Добавяне на бутон „Твърдение“ в лентата с инструменти за твърдения на тестовата стъпка

Стъпка 2: Сега изберете категорията „Твърдение“.

  1. В този случай това е скрипт.
  2. Изберете SoapUI Твърдение на скрипт и няма свързани с него подтипове.
  3. Кликнете върху „Добавяне“.

Добавяне на диалогов прозорец за твърдение с избрана категория „Скрипт“

Стъпка 3: Отваря се диалоговият прозорец за скриптове, където потребителят ще може да напише дефиниран от потребителя скрипт, за да валидира XML файла на отговора.

Празен SoapUI диалогов прозорец на редактора за твърдения на скриптове

Стъпка 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"}
  1. Щракнете върху бутона „Изпълнение“, за да задействате изпълнението.
  2. Резултатът от скрипта се показва в прозореца Изход. Той е отпечатал както стойността на преобразуването, така и крайния резултат (успешен или неуспешен)
  3. Показва се информацията, че „Script Assertion Passed“. Натиснете OK.

Забележка: Последният изскачащ прозорец с информация винаги ще се показва със съобщението „Утвърждението на скрипта е преминало“, стига скриптът да е синтактично правилен. Няма връзка с вашето твърдение в сценария.

Изходен панел за твърдение на скрипта, отпечатващ резултатната стойност и Pass

натиснете ОК

Стъпка 5: Сега разделът „твърдения“ показва всички твърдения, които сме добавили за този тестов набор, със статуса на всяко едно от тях.

Раздел „Твърдения“, в който е изброено всяко твърдение, добавено към тестовия пакет

Стъпка 6: Сега

  1. Изберете пакета за тестване от дървото на навигатора
  2. Щракнете върху бутона „Изпълни“.
  3. Резултатите ще бъдат показани за целия набор от тестове.

Резултати от изпълнението на тестовия пакет след изпълнение на всички твърдения

Твърдение за съвпадение в XQuery

Той използва XQuery израз, за ​​да избере съдържание от целевото свойство. Нуждаем се от много по-голям XML отговор, за да разберем по-добре XQuery твърдението в SoapUIНека импортираме още един WSDL, както е показано по-долу: http://www.webservicex.net/medicareSupplier.asmx?WSDL

Забележка: Публичните демонстрационни крайни точки на webservicex.net, използвани в това ръководство, вече не са надеждно достъпни, така че екранните снимки на заявки и отговори по-долу се запазват като референтен пример. Всеки WSDL, който връща повтарящ се набор от възли, ще упражни XQuery твърдението по абсолютно същия начин.

Стъпка 1: Щракнете с десния бутон върху съществуващия проект и изберете „Добавяне на WSDL“.

Меню с десния бутон върху SoapUI проект, показващ Добавяне на WSDL

Стъпка 2: Отваря се диалоговият прозорец „Добавяне на WSDL“. Оставете другите опции по подразбиране и щракнете върху бутона „OK“.

Добавяне на WSDL диалогов прозорец с опции за импортиране по подразбиране

Стъпка 3: Всички операции са изброени, както е показано по-долу.

WSDL операциите на доставчика на Medicare, изброени в дървото на навигатора

Стъпка 4: Сега нека добавим Тестов случай в рамките на същия тестов пакет, за който създадохме Тестване валутен конвертор.

Нова опция TestCase в съществуващия набор от тестове

Стъпка 5: Въведете името на тестовия случай и щракнете върху бутона „OK“

Въвеждане на името на тестовия случай в диалоговия прозорец „Нов тестов случай“

Стъпка 6: Тестовият случай се създава, както е показано по-долу.

Новосъздаден тестов случай в SoapUI навигационно дърво

Стъпка 7: Добавете нова тестова стъпка от тип „Заявка за тест на SOAP“, както е показано по-долу.

Меню „Добавяне на стъпка“ с избрана заявка за SOAP тест

Стъпка 8: Въведете името на тестовата стъпка. Да кажем – Supplier_by_City, което би било по-смислено. Кликнете върху „OK“.

Именуване на новата тестова стъпка Supplier_by_City

Стъпка 9: Изберете Operaция, която бихме искали да валидираме. В този случай това е „MedicareSupplierSoap -> GetSupplierByCity“. Кликнете върху „OK“.

Избиране на операцията GetSupplierByCity за тестовата стъпка

Стъпка 10: Въведете името на тестовия случай и щракнете върху „OK“.

Потвърждаване на името на заявката за SOAP тест

Стъпка 11: XML структурата на заявката ще се покаже, както е показано по-долу.

Генериран XML контур на заявка за GetSupplierByCity

Стъпка 12: Сега нека намерим цялата информация за доставчиците за град „Ню Йорк“.

За да направите това, добавете следните редове към вашия код.

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

<City>New York</City>

</GetSupplierByCity>

WSDL по-долу URL – http://www.webservicex.net/medicareSupplier.asmx?op=GetSupplierByCity

XML заявка, редактирана с Ню Йорк като стойност за град

Стъпка 13: След изпълнение на теста получаваме следния отговор

Отговор на GetSupplierByCity, съдържащ повтарящи се записи на доставчици

Стъпка 14: Да кажем, че трябва да валидираме всички номера на доставчици. Не можем да използваме XPath Assertion, тъй като се нуждаем от стотици XPath Assertion. Следователно използването на XQuery е неизбежно в този случай.

XQuery Assertion ни помага да валидираме група от XML отговори, които са повтарящи се по природа.

Повтарящи се възли SupplierData, които XQuery ще итерира през

Стъпка 15: Сега кликнете върху „Добавяне на твърдение“,

  1. Изберете „Категория на твърдението“ – в този случай съдържание на собственост.
  2. Изберете типа твърдение като „XQuery твърдение“
  3. Кликнете върху „Добавяне“.

Твърдение XQuery, избрано в категорията „Съдържание на свойство“

Стъпка 16: Подобно на XPath Assertion, трябва да декларираме пространството от имена.

  1. Кликнете върху бутона „Деклариране“, за да разрешите автоматично SoapUI за да декларирате пространството от имена. След щракване върху бутона за деклариране, на потребителя ще се покаже „изскачащ прозорец“ със съобщението „декларирайте пространството от имена от схема вместо това“. Щракнете върху „Да“, за да продължите, както е показано по-долу.
  2. За да извлечем целия номер на доставчик, трябва да напишем XPath заявка и ще я поставим в < SupplierNumber> и Етикети.
  3. Щракнете върху „Избор от текущия“, който ще се изпълни от текущия отговор.
  4. След като щракнете върху „Избери от текущите“, ще бъдат изброени всички номера на доставчици.
  5. Щракнете върху „Запазване“.

Деклариране на пространство от имена от изскачащ прозорец за потвърждение на схемата

Забележка: След натискане на бутона „Деклариране“ може да се окажете с различни 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)}
}

Прозорец с XQuery изрази, изброяващ всеки номер на доставчик

Стъпка 17: XQuery твърдението се изпълнява и показва крайния резултат в панела „Твърдение“, както е показано по-долу. Сега успешно добавихме XQuery твърдение, с което валидирахме цялата информация за номера на доставчика. Същата ще се сравнява с действителните стойности всеки път, когато заявката се изпраща към уеб сървъра.

Забележка: Действителните стойности няма да бъдат показани. Ако всички действителни стойности са същите като тези на очакваните стойности, тогава се показва VALID, в противен случай ще се покаже „Неуспешно“.

Панелът с твърдения, показващ резултата от XQuery твърдение

Кога да използвате вградено твърдение?

След като са обхванати както опциите за кликване с посочване, така и скриптовите, практическият въпрос е кой да изберете.

  • Когато отговорът е кратък, така че да може да бъде валидиран с помощта на едно от тези вградени твърдения.
  • Можем също да използваме Inbuilt Assertion, ако отговорът, изпратен от уеб сървъра, винаги е статичен по природа. Ако е динамичен, няма да можем да го потвърдим с помощта на вградени твърдения.
  • Когато използването на вградени твърдения като твърдения за изчакване и твърдения за сигурност стане неизбежно.
  • Вградените твърдения се държат доста добре за еднократна употреба, когато тестовете не трябва да се повтарят.

Опции за твърдения

Създадените твърдения могат да се контролират най-добре с помощта на контролния панел, който е маркиран по-долу.

Контролен панел на кутията с инструменти за твърдения в SoapUI

Създадените твърдения позволяват на тестерите да конфигурират следните неща от кутията с инструменти за твърдения.

Опция 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“, което означава, че проблемът е с параметъра, който се предава от страна на клиента. Заявката, носеща невалидната стойност, се показва първа.

SoapUI заявка за предаване на невалидна нецялочислова стойност за intA

Отговорът връща кода на грешката вместо резултат, както е показано по-долу.

Кодът за грешка на SOAP-клиента, върнат в SoapUI редактор на отговори

Уверете се, че използвате правилния синтаксис, когато използвате XPath и XQuery твърдение. НЕ трябва да използвате dot(.) вместо colon(:), когато използвате горното твърдение. Синтаксисът е //namespace:Tagname, а НЕ //namespace.tagname. По този начин може да получите съобщение „НЯМА съвпадение в текущия отговор“, въпреки че името на тага е правилно.

Няма съвпадение в текущия отговор, грешка, причинена от неправилен XPath синтаксис

Въпроси и Отговори

Всяко число. SoapUI прилага всяко твърдение, прикрепено към стъпка от тест на семплер, след като тя се изпълни, и стъпката се маркира като неуспешна в изгледа на тестовия случай, ако дори едно от тези твърдения е неуспешно.

Той сравнява XML съобщение с очаквания документ възел по възел, така че избраните полета могат да бъдат игнорирани или съпоставени свободно, вместо целият полезен товар да се третира като един обикновен низ.

С отворен код SoapUI обхваща съдържанието на свойствата, съответствието, скриптовете, SLA, JMS и сигурността. ReadyAPI добавя групаping, клониране, JDBC проверки и активиране или деактивиране на контрола.

Моделите с изкуствен интелект четат примерен отговор и предлагат XPath или XQuery изрази, предлагат гранични стойности и маркират полета, които се променят при всяко изпълнение – което значително намалява работата с ръчно писаното пространство от имена и изрази.

Да. втори пилот автоматично довършване GroovyUtils и XmlHolder шаблонен код. Винаги изпълнявайте скрипта първо, защото синтактично валидният скрипт докладва „Script Assertion Passed“, независимо от сравнението.

Да. Полетата за съдържание на твърдения поддържат разширяване на свойства, така че очакваната стойност може да бъде извлечена от свойство на проект или тестов случай, а не от литерал, което прави едно твърдение многократно използваемо в различни среди.

Неуспешно твърдение маркира своята тестова стъпка като неуспешна в изгледа на тестовия случай и записва съответстващ запис FAILED, с подробности за неуспеха, в дневника на изпълнението на теста в долната част на прозореца.

Съдържа, Не съдържа, XPath съвпадение, XQuery съвпадение, SLA на отговор, скрипт, валидни и невалидни HTTP кодове за състояние, разкриване на чувствителна информация и съответствие на схемата с WADL или изведена схема.

Обобщете тази публикация с: