Здравейте всички. Бавно излизаме от сенките и продължаваме поредицата от статии за нашия продукт. След предишен статия за преглед, получихме много отзиви (предимно положителни), предложения и доклади за грешки. Днес ще покажем TestMace в действие и ще можете да оцените някои от функциите на нашето приложение. За по-пълно потапяне ви съветвам да се обърнете към нашата документация на адрес http://docs-ru.testmace.com. Така че, да тръгваме!

Инсталация

Да започнем с баналността. Приложението е достъпно и реално тествано на три платформи - Linux, Windows, MacOS. Можете да изтеглите инсталатора за операционната система, която ви интересува нашия уебсайт. За потребители на Linux е възможно да се инсталира модулен пакет. Наистина се надяваме, че Microsoft Store и App Store скоро ще го намерят (необходимо ли е? Какво мислите?).

Експериментален сценарий

Избрахме следния стандартен сценарий като наш тестов обект:

• Вход: потребител - admin, парола - парола
• добавете нов запис
• Нека проверим дали записът е добавен правилно

Ще тестваме на https://testmace-quick-start.herokuapp.com/. Това е нормално json-сървър, идеален за тестване на такива приложения. Току-що добавихме оторизация чрез токен към всички маршрути на json-сървър и създадохме метод за влизане за получаване на този токен. Ще се движим прогресивно, като постепенно подобряваме проекта си.

Създаване на проект и опит за създаване на обект без разрешение

Първо, нека създадем нов проект (досие->Нов проект). Ако стартирате приложението за първи път, автоматично ще се отвори нов проект. Първо, нека се опитаме да направим заявка за създаване на нов запис (в случай че създаването на записи е достъпно без разрешение). Изберете елементи от контекстното меню на възела на проекта Добавете възел -> RequestStep. Задайте името на възела на създаване на публикация. В резултат на това в дървото ще бъде създаден нов възел и ще се отвори раздел за този възел. Нека зададем следните параметри на заявката:

• Тип заявка: POST
• URL адрес: https://testmace-quick-start.herokuapp.com/posts
• Тяло на заявката: json със стойност {"title": "New testmace quick start post"}
  Ако сте направили всичко правилно, интерфейсът ще изглежда така:

Ако обаче се опитаме да изпълним заявката, сървърът ще върне код 401 и без разрешение няма да получим нищо на този сървър. Е, като цяло, както се очаква).

Добавяне на заявка за оторизация

Както вече казахме, имаме POST крайна точка /login, който приема json като тяло на заявка във формата: {"username": "<username>", "password": "<password>"}Където username и password (отново от уводния параграф по-горе) имат значения admin и password съответно. В отговор тази крайна точка връща json like {"token": "<token>"}. Ще го използваме за оторизация. Да творим RequestStep възел с име Влизане, ще действа като предшественик Проект възел Използвайки плъзгане и пускане, преместете даден възел в дървото по-високо от възела създаване на публикация. Нека зададем следните параметри на новосъздадената заявка:

• Тип заявка: POST
• URL адрес: https://testmace-quick-start.herokuapp.com/login
• Тяло на заявката: json със стойност {"username": "admin", "password": "password"}

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

Рефакторинг: премахване на дублиране на домейн

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

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

Нека дефинираме променлива на ниво възел на проекта domain със стойност https://testmace-quick-start.herokuapp.com. За това е необходимо

• Отворете раздела с този възел и щракнете върху иконата на калкулатора горе вдясно
• Кликнете върху + ДОБАВЯНЕ НА ПРОМЕНЛИВА
• Въведете име и стойност на променливата
  В нашия случай диалогът с добавената променлива ще изглежда така:

ДОБРЕ. Сега, поради наследяването, можем да използваме тази променлива в наследници на всяко ниво на влагане. В нашия случай това са възли Влизане и създаване на публикация. За да използвате променлива в текстово поле, трябва да пишете ${<variable_name>}. Например URL адресът за вход се преобразува в ${domain}/login, съответно за създаване на публикация URL адресът на възела ще изглежда така ${domain}/posts.

Така, водени от принципа DRY, леко подобрихме сценария.

Запазете токена в променлива

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

Първо, нека изпълним заявка за влизане. В раздела Анализиран отговор, преместете курсора върху токена и в контекстното меню (което се извиква с десния бутон на мишката или чрез щракване върху бутона ...) изберете елемента Присвояване на променлива. Ще се появи диалогов прозорец със следните полета:

• Път — коя част от отговора се взема (в нашия случай е body.token)
• Текуща стойност — каква стойност се крие по пътя (в нашия случай това е символичната стойност)
• Име на променливата — име на променливата where Текуща стойност ще бъдат запазени. В нашия случай ще бъде token
• Възел — в кой от предците ще бъде създадена променливата Име на променливата. Нека изберем Project

Завършеният диалогов прозорец изглежда така:

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

За достъп до динамични променливи трябва да използвате вградена променлива $dynamicVar. Например, за достъп до съхранен токен, трябва да се обадите ${$dynamicVar.token}.

Предаваме маркера за оторизация в заявките

В предишните стъпки получихме токена за оторизация и всичко, което трябва да направим, е да добавим заглавка Authorization със смисъл Bearer <tokenValue> във всички заявки, изискващи оторизация, вкл създаване на публикация. Има няколко начина да направите това:

1. Копирайте ръчно токена и добавете заглавка за оторизация към заявките, които представляват интерес. Методът работи, но използването му е ограничено само до заявки от типа „направено и изхвърлено“. Не е подходящ за многократно изпълнение на скриптове
2. Използвайте функционалността оторизация.
3. употреба заглавки по подразбиране

Използването на втория метод изглежда очевидно, но в контекста на тази статия този подход е... безинтересен. Е, наистина: механизмът за оторизация плюс минус ви е познат от други инструменти (дори ако имаме неща като наследяване на авторизация) и е малко вероятно да предизвика въпроси.

Друго нещо са заглавките по подразбиране! С две думи, заглавките по подразбиране са наследени HTTP заглавки, които се добавят към заявката по подразбиране, освен ако изрично не са деактивирани. Използвайки тази функционалност, можете например да приложите персонализирано оторизиране или просто да се отървете от дублиране в скриптове. Нека използваме тази функция, за да предадем токен в заглавките.

Преди това предпазливо запазихме токена в динамична променлива $dynamicVar.token на ниво възел на проекта. Всичко, което остава, е да направите следното:

1. Определете заглавие по подразбиране Authorization със стойност Bearer ${$dynamicVar.token} на ниво възел на проекта. За да направите това, в интерфейса на проекта на възела трябва да отворите диалогов прозорец със заглавия по подразбиране (бутон Заглавия в горния десен ъгъл) и добавете съответното заглавие. Диалогът с попълнените стойности ще изглежда така:
   
2. Деактивирайте тази заглавка от заявката за влизане. Това е разбираемо: към момента на влизане все още нямаме токен и ще го инсталираме с тази заявка. Следователно в интерфейса за влизане на заявката в раздела Заглавия в района на наследен премахнете отметката от заглавката за оторизация.

Това е всичко. Сега заглавката за оторизация ще бъде добавена към всички заявки, които са деца на възела на проекта, с изключение на възела за влизане. Оказва се, че на този етап вече имаме готов скрипт и остава само да го стартираме. Можете да стартирате скрипта, като изберете бягане в контекстното меню на възела на проекта.

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

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

• Изпратете заявка за получаване на публикация по id,
• Проверете дали името, получено от сървъра, съвпада с името, изпратено при създаване на публикацията

Нека разгледаме първата стъпка. Тъй като стойността на id се определя по време на изпълнение на скрипта, трябва да създадете динамична променлива (да я наречем postId) от възел създаване на публикация на ниво възел на проекта. Вече знаем как да направим това, просто вижте раздела Запазете токена в променлива. Остава само да създадете заявка за получаване на публикация с този идентификатор. За да направите това, нека създадем RequestStep get-post със следните параметри:

• Тип заявка: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

За да изпълним втората стъпка, трябва да се запознаем с Твърдение възел. Възелът Assertion е възел, който ви позволява да пишете проверки за конкретни заявки. Всеки възел Assertion може да съдържа няколко твърдения (проверки). Можете да прочетете повече за всички видове твърдения от нашия документация. Ще използваме Compare твърдение с оператор equal. Има няколко начина за създаване на твърдения:

1. Дълги. Създайте ръчно възел Assertion от контекстното меню на възела RequestStep. В създадения възел Assertion добавете твърдението за интерес и попълнете полетата.
2. Бърз. Създайте възел Assertion заедно с твърдение от отговора на възела RequestStep, като използвате контекстното меню

Нека използваме втория метод. Ето как ще изглежда за нашия случай.

За тези, които не разбират, ето какво се случва:

1. Направете заявка във възела get-post
2. В раздела Анализиран отговор, извикайте контекстното меню и изберете Създайте твърдение -> сравнение -> равен

Поздравления, създадохме първия си тест! Просто, нали? Сега можете да стартирате скрипта напълно и да се насладите на резултата. Остава само да го преработим малко и да го извадим title в отделна променлива. Но ще оставим това за вас като домашна работа)

Заключение

В това ръководство създадохме пълноценен сценарий и в същото време прегледахме някои от функциите на нашия продукт. Разбира се, ние не използвахме цялата функционалност и в следващите статии ще предоставим подробен преглед на възможностите на TestMace. Останете на линия!

PS За тези, които са твърде мързеливи, за да възпроизведат всички стъпки, любезно записахме хранилище с проекта от статията. Можете да го отворите с досие -> Отворен проект и изберете папката Project.

Източник: www.habr.com