Как да създадете Test Suite & Test Case в SoapUI

Разбиране на SOAP протокола

Преди да създадем тестов случай на SOAPUI, нека разберем основите на протокола SOAP. Това ще ви помогне да използвате SOAP UI за ефективно тестване на SOAP заявки и отговор.

SOAP означава Прост протокол за достъп до обект. По-долу са свойствата на SOAP протокол.

Това е базиран на XML протокол за комуникация между две различни системи.
Това е платформа и независим език. Следователно, система, разработена с помощта на Java може да комуникира със система, разработена в .NET.
SOAP заявките/отговорите се транспортират чрез HTTP.

Научете ФОРМАТА на SOAP съобщението

SOAP съобщение е обикновен XML документ, съдържащ следните елементи. Съобщението може да бъде или съобщение за заявка, или съобщение за отговор.

След като настроихме работното пространство, което изпълнихме в последния урок, трябва да създадем структура на проекта SoapUI, тестови пакети, тестови случаи, за да тестваме дадена уеб услуга. Нека разберем пример за проект SoapUI, за да създадем нов SOAP проект.

Създаване на SOAP проект

Стъпка 1) Сега, в зависимост от проекта, трябва да импортираме SOAP/REST протокол. Ще създадем нов SOAP проект.

Стъпка 2) Ще използваме следната SOAP заявка http://www.dneonline.com/calculator.asmx?wsdl

Въведете името на проекта
Въведете пътя на WSDL заявката. В този случай http://www.dneonline.com/calculator.asmx?wsdl
натиснете ОК

Забележка:

Създаване на примерна заявка за всички операции? Той създава примерна заявка за всички налични операции в дадения WSDL. Веднага щом въведете WSDL адреса, тази опция се маркира автоматично. Можете да премахнете отметката.
Създайте тестов пакет за импортирания WSDL: Създава тестов пакет SoapUI в рамките на проекта за импортирания WSDL.
Относителни пътища: Позволява на потребителя да запази всички файлове, свързани с файла на проекта.

Стъпка 3) При създаването на SOAP проекта с горепосочения WSDL ще можем да видим, че има две операции, които ще бъдат импортирани в проекта.

Стъпка 4) Разгънете първата заявка и щракнете с десния бутон върху „Добавяне“. След това щракнете върху „Нова заявка“.

След това щракнете върху „OK“. Той ще покаже SOAP заявката в XML формат

Въведете „intA“ и „intB“
Щракнете върху бутона за изпращане
От дясната страна ще се покаже XML отговор.

Може би се чудите защо създавате тестови случаи? Когато можете директно да тествате Webservice тук...

Е, можете да изпратите заявка за една операция. Ами другите? Колко комбинации от входове за Additions можете да направите, като използвате тази операция? Трябва да редактирате заявката за всяка комбинация.

Например: Ако искате да добавите от 4 и 4 вместо от 5 и 5… Трябва да редактирате операцията отново. Така че трябва да се създаде тестов пакет/случаи, за да се тестват всички възможни сценарии, без да се налага директно да се редактира самата операция.

Как да създадете тестов пакет в SoapUI

По-долу са стъпките за създаване на тестов пакет в SoapUI:

Стъпка 1) Щракнете с десния бутон върху корена на проекта

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

Стъпка 2) Въведете подробностите за тестовия пакет

Трябва да въведем името на тестовия пакет и да натиснете OK.

Стъпка 3) Проверете създадения тестов пакет

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

Стъпка 4) Отворете тестовия пакет

Прозорецът на тестовия пакет се отваря в десния панел. Както току-що създадохме, НЯМА тестови случаи на SoapUI. Следователно всички опции са деактивирани.

Как да създадете тестов случай в SoapUI

Ето стъпка по стъпка процес за създаване на тестов случай в SoapUI:

Стъпка 1) В рамките на тестов пакет можем да създадем множество тестове, като щракнете с десния бутон върху „тестовия пакет“ и изберете „Нов тестов случай“.

Стъпка 2) Посочете името на Тестов случай и щракнете върху „OK“.

Стъпка 3) Създаденият тестов случай има нула стъпки, както е показано по-долу.

Забележка: Виждаме, че тестовият случай е добавен с нулеви тестови стъпки за всички видове налични тестове. При добавяне на тестовите стъпки, числата в скобата ще се променят автоматично.

Стъпката на функционалния тест трябва да влезе в „Тестови стъпки“, докато стъпката на тест на производителността трябва да влезе в „Тест за натоварване“, а стъпката на тест за сигурност трябва да отиде в „Тестове за сигурност“.

Стъпка 4) Можем да вмъкнем различни тестови стъпки, като щракнем с десния бутон върху тестовите стъпки и изберем подходяща тестова стъпка, както е показано по-долу. Така че, ако трябваше да тествате REST уеб услуга, бихте избрали REST Test Request.

Добавяне на тестова стъпка в SoapUI

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

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

Стъпка 2) Въведете името на стъпката и щракнете върху OK.

Стъпка 3) След като щракнете върху „OK“, се появява диалогов прозорец за избор на операцията, която да се извика. Всички операции са изброени и потребителят може да избере операцията, която иска да извика.

Има много операции, които ще бъдат изброени. The Operaса същите, с изключение на използваната SOAP версия. CalculatorSoap – използва SOAP версия 1.1, докато CalculatorSoap12 – използва SOAP версия 1.2
Версията няма значение за нас в този контекст. Следователно можете да изберете този по ваш избор.
След като изберете операцията, щракнете върху „Ok“

Стъпка 4) Докато добавяме тестов случай, можем да добавим стандартни твърдения. Твърденията, наричани още контролни точки/точки за валидиране, с които ще се занимаваме подробно в следващия урок.

Можем да добавим следните контролни точки/твърдения, докато създаваме тестов случай. Нека създадем тестов случай с опцията, която означава създаване на тестова стъпка БЕЗ някоя от точките за валидиране по-долу

Проверява дали съобщението за отговор е SOAP при изпълнение на теста.
Проверява дали схемата за отговор е валидна.
Проверява дали SOAP отговорът съдържа FAULT.

Стъпка 5) При създаването на тестовия случай XML заявката е показана по-долу. Структурата на XML е обяснена в моментната снимка по-долу.

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

Ръчно изпращане на заявка и четене на отговор в SoapUI

Стъпка 1) Бихме искали да добавим две цели числа.

intA – 5
intB – 5

След

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

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

Като прочетем отговора, можем да заключим, че 5 плюс 5 е 10.

Разбиране на Soap Response & Log Panels

Както е обяснено в началото на този урок за тестване на SoapUI, SOAP съобщенията се транспортират чрез HTTP протокол. Нека да разгледаме RAW съобщенията. Това ще ни помогне да научим как SOAP заявката и отговорът са били транспортирани чрез HTTP.

Стъпка 1) Щракнете върху раздела „RAW“ в двата прозореца за заявка на SOAP-UI.

Заявката се публикува на уеб сървъра. Следователно се използва методът POST на Http.
SOAP заявката се транспортира в тялото на Http съобщението.

Стъпка 2) Сега щракнете върху раздела „RAW“. в прозореца за отговор на SOAP-UI, за да разберете как отговорът се изпраща чрез HTTP.

След обработка на заявката се показва Http кодът за отговор (200), което означава, че е успешна. Уеб сървърът го е обработил успешно.
SOAP отговорът се изпраща обратно на клиента като част от тялото на HTTP съобщението.

Бърза моментна снимка на кодовете за Http Response за лесно разбиране и отстраняване на грешки. Таблицата по-долу ще ви помогне да отстраните проблеми въз основа на HTTP кода, получен от уеб сървъра.

Http код	Descriptйон
1xx:	Информационен – Това означава получена заявка и продължаващ процес.
2xx:	Успех – Действието беше успешно получено, разбрано и прието.
3xx:	Пренасочване – Това означава, че трябва да се предприемат допълнителни действия, за да се изпълни заявката.
4xx:	Грешка на клиента – Това означава, че заявката съдържа лош синтаксис или не може да бъде изпълнена
5xx:	Грешка в сървъра – Сървърът не успя да изпълни привидно валидна заявка

Стъпка 3) Нека разберем другата информация, която се показва в прозореца на тестовия случай.

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

ПАНЕЛ ЗА Дневници:

Панелът с регистрационни файлове съдържа пълна информация относно транзакцията между клиента и сървъра. Потребителите ще могат да виждат разделите на панела на регистрационния файл, както е показано по-долу. Ще обсъдим най-често използваните регистрационни панели при работа със SOAP-UI.

Дневник на SoapUI – Показва информацията за отговор от уеб сървъра. Същата информация се съхранява във файла soapui.log на инсталираната папка на SOAP-UI в директорията „bin“.

Http дневник – Показва целия трансфер на HTTP пакети. Цялата информация в „RAW“ се показва в HTTP журнала.

Регистър на грешките – Регистърът на грешките показва всички грешки, които сме срещнали по време на цялата сесия на проекта. Същата информация е налична в „soapui-errors.log“, присъстващ в директорията „bin“ на инсталираното местоположение на SOAP UI.

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

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