Разбиране на SOAP протокола
Преди да създадем SOAPUI тестов случай, нека разберем основите на SOAP протокола. Това ще ви помогне да използвате SOAP UI за тестване на SOAP заявки и отговор ефективно.
SOAP означава S изпъл О bject A ДОСТЪП P rotocol. По-долу са описани свойствата на SOAP протокола.
- Това е XML-базиран протокол за комуникация между две различни системи.
- Това е платформа и език, независими. Следователно, система, разработена с помощта на Java, може да комуникира със система, разработена в .NET.
- SOAP заявките / отговорите се транспортират чрез HTTP.
В този урок за тестване ще научите:
- Научете ФОРМАТА на SOAP съобщението
- Създайте проект
- Създаване на Test Suite
- Създаване на тестов случай
- Вмъкване на тестова стъпка
- Разбиране на панелите за реакция на сапун и дневник
- Изпращане на заявка ръчно и отговор за четене
Научете ФОРМАТА на SOAP съобщението
SOAP съобщението е обикновен XML документ, съдържащ следните елементи. Съобщението може да бъде или съобщение за заявка, или съобщение за отговор.
След настройването на работното пространство, което бяхме изпълнили в последния урок, трябва да създадем проекти, тестови пакети, тестови случаи, за да тестваме дадена уеб услуга. Нека разберем стъпките, свързани с това.
Създайте проект
Стъпка 1: Сега, в зависимост от проекта, трябва да импортираме SOAP / REST протокол. Ще създадем нов проект SOAP.
Стъпка 2: Ще използваме следната заявка за SOAP http://www.dneonline.com/calculator.asmx?wsdl
- Въведете името на проекта
- Въведете пътя на WSDL заявката. В този случай http://www.dneonline.com/calculator.asmx?wsdl
- Щракнете върху OK
Забележка:
- Създаване на примерна заявка за всички операции? Създава примерна заявка за всички налични операции в дадения WSDL. Веднага след като въведете WSDL адреса, тази опция се проверява автоматично. Можете да го махнете.
- Създаване, тестов пакет за импортирания WSDL: Създава тестов пакет в рамките на проекта за импортирания WSDL.
- Относителни пътища : Позволява на потребителя да запазва всички файлове, свързани с файла на проекта.
Стъпка 3: След създаването на SOAP проекта с гореспоменатия WSDL, ще можем да видим, че има две операции, които ще бъдат импортирани в проекта.
Стъпка 4)
Разгънете първата заявка и щракнете с десния бутон върху „Добавяне“. След това кликнете върху „Нова заявка“.
След това кликнете върху „OK“. Той ще покаже заявката SOAP във формат XML
- Въведете „intA“ и „intB“
- Щракнете върху бутона за изпращане
- XML за отговор ще се покаже в дясната страна.
Може би се чудите защо да създавате тестови случаи? Когато можете директно да тествате Webservice тук
...Е, можете да изпратите заявка за една операция. Ами другите? Колко комбинации от входове за добавки можете да направите, като използвате тази операция ? Трябва да редактирате заявката за всяка комбинация.
Например: Ако искате да добавите от 4 и 4 вместо от 5 и 5
... Трябва да редактирате операцията отново. Така че, трябва да се създаде тестов пакет / случаи, за да се тестват всички възможни сценарии, без да се налага директно да се редактира самата операция.Създаване на Test Suite
Стъпка 1: В рамките на проекта тестерите могат да създадат набор от тестове, като изпълнят десен бутон на мишката върху корена на проекта.
Стъпка 2: Трябва да въведем името на тестовия пакет и да натиснем OK.
Стъпка 3: Създаденият тестов пакет се показва на панела за навигация, както е показано по-долу.
Стъпка 4: Прозорецът за тестов пакет се отваря в десния екран. Както току-що създадохме, НЯМА тестови случаи. Следователно всички опции са деактивирани.
Създаване на тестов случай
Стъпка 1: В рамките на тестов пакет можем да създадем множество тестове, като извършим десен бутон на мишката върху „тестовия пакет“ и изберете „New TestCase“
Стъпка 2: Посочете името на тестовия случай и кликнете върху „OK“.
Стъпка 3: Създаденият тестов случай има нула стъпки, както е показано по-долу.
Забележка : Можем да видим, че тестовият случай е добавен с нулеви стъпки за всички налични видове тестове. При добавяне на тестовите стъпки номерата в скобата ще се променят автоматично.
Стъпката за функционален тест трябва да премине в „Тестови стъпки“, докато стъпката за тестване на производителността трябва да премине в „Тест за натоварване“, а стъпката за тест за сигурност трябва да премине в „Тестове за сигурност“.
Стъпка 4: Можем да вмъкнем различни тестови стъпки, като изпълним с десен бутон върху тестовите стъпки и изберем подходяща тестова стъпка, както е показано по-долу. Така че, ако трябваше да тествате REST Webservice, бихте избрали REST Test Request.
Вмъкване на тестова стъпка
Сега нека добавим тестова стъпка за валидиране на импортираната SOAP заявка.
Стъпка 1: Добавете нова стъпка „SOAP Request“, както е показано по-долу.
Стъпка 2: Въведете името на стъпката и щракнете върху OK.
Стъпка 3: След като щракнете върху „OK“, изскача диалогов прозорец, за да изберете операцията, която да се извика. Всички операции са изброени и потребителят може да избере операцията, която би искал да извика.
- Има много операции, които ще бъдат изброени. Операциите са същите, с изключение на използваната версия SOAP.
CalculatorSoap - използва SOAP версия 1.1, докато,
CalculatorSoap12 - използва SOAP версия 1.2
- Версията няма значение за нас в този контекст. Следователно можете да изберете този по ваш избор.
- След като изберете операцията, щракнете върху „Ok“
Стъпка 4: Докато добавяме тестов случай, можем да добавим стандартни твърдения. Твърденията също се наричат контролни точки / точки за валидиране, които ще разгледаме подробно в следващия урок.
Можем да добавим следните контролни точки / твърдения, докато създаваме тестов случай. Нека създадем тестов случай с опцията, което означава създаване на тестова стъпка БЕЗ някоя от долните точки за валидиране
- Проверява дали съобщението за отговор е SOAP при изпълнение на теста.
- Проверява дали схемата за отговор е валидна.
- Проверява дали SOAP отговорът съдържа FAULT.
Стъпка 5: След създаване на тестовия случай, XML заявката е показана по-долу. Структурата на XML е обяснена в снимката по-долу.
Стъпка 6: Броят на тестовите стъпки вече се увеличава до един, тъй като току-що добавихме една тестова стъпка. По същия начин, при добавяне на стъпка от тестове за натоварване и сигурност, съответният номер ще бъде автоматично увеличен въз основа на броя на добавените стъпки.
Изпратете заявка ръчно и отговор за четене
Стъпка 1: Бихме искали да добавим две цяло число.
- intA - 5
- intB - 5
Следващия,
- Трябва да въведем тези данни вместо въпросния знак, който ще бъде изпратен като XML за заявка.
- След като въведете тези стойности в съответните XML тагове, щракнете върху бутона „подаване на заявка“, за да проверите отговора.
Стъпка 2: След подаване на заявка заявката за уеб услуга се обработва от уеб сървъра и изпраща обратно отговор, както е показано по-долу.
Четейки отговора, можем да заключим, че 5 плюс 5 е 10.
Разбиране на панелите за реакция на сапун и дневник
Както е обяснено в началото на този урок, SOAP съобщенията се транспортират чрез HTTP протокол. Нека да разгледаме RAW съобщенията. Това ще ни помогне да научим как заявката и отговорът на SOAP са били транспортирани чрез HTTP.
Стъпка 1: Щракнете върху раздела „RAW“ в прозореца за заявка SOAP-UI.
- Искането се публикува на уеб сървъра. Следователно се използва методът POST на Http.
- Заявката за SOAP се транспортира в тялото на съобщението Http.
Стъпка 2: Сега кликнете върху раздела „RAW“ в прозореца за отговор на SOAP-UI, за да разберете как се изпраща отговорът чрез HTTP.
- След обработка на заявката се показва Http кодът за отговор (200), което означава, че е успешен. Уеб сървърът го е обработил успешно.
- Отговорът SOAP се изпраща обратно на клиента като част от тялото на HTTP съобщението.
Бърза снимка на кодовете за Http отговор за лесно разбиране и отстраняване на грешки. Таблицата по-долу ще ви помогне да решите проблемите въз основа на HTTP кода, получен от уеб сървъра.
| Http код | Описание |
| 1xx: | Информационен - Това означава получена заявка и продължаващ процес. |
| 2xx: | Успех - Действието беше успешно получено, разбрано и прието. |
| 3xx: | Пренасочване - Това означава, че трябва да се предприемат допълнителни действия, за да се попълни заявката. |
| 4xx: | Клиентска грешка - Това означава, че заявката съдържа лош синтаксис или не може да бъде изпълнена |
| 5xx: | Грешка на сървъра - сървърът не успя да изпълни очевидно валидна заявка |
Стъпка 3: Нека разберем другата информация, която се показва в прозореца на тестовия случай.
- Представете НЕ заглавка в заявката, която се изпраща
- Представлява БЕЗ прикачени файлове в заявката, която се изпраща до уеб сървъра.
- Представлява 10 заглавна информация и същите се показват при щракване върху нея.
- Представлява, че няма прикачени файлове от съобщението за отговор.
ТЪРСЕНЕ НА ЛОГИ:
Екранът за регистрационни файлове съдържа пълна информация относно транзакцията между клиента и сървъра. Потребителите ще могат да виждат разделите на прозореца на дневника, както е показано по-долу. Ще обсъдим най-често използваните дневници при работа с SOAP-UI.
SoapUI Log - Показва информацията за отговора от уеб сървъра. Същата информация се съхранява във файла soapui.log на инсталираната папка SOAP-UI в директорията 'bin'.
Http Log - Показва целия HTTP трансфер на пакети. Цялата информация в „RAW“ се показва в HTTP регистъра.
Дневник на грешките - Дневникът на грешките показва всички грешки, които сме срещали по време на цялата сесия на проекта. Същата информация е налична в 'soapui-errors.log' в директорията 'bin' на инсталираното местоположение на SOAP UI.
Log Log - Този раздел следи консумацията на памет и го показва под формата на диаграмата, както е показано по-долу. Наистина е полезно, когато има операция с интензивна памет.
След като създадохме тестов пакет, тестов случай, тестова стъпка и получихме отговор, следващата стъпка е да проверим отговора. Ще се справим с типовете твърдения в следващия урок.