Меню

Розширені сценарії для комплексного тестування робочих процесів у листоноші

  • Головна
  • Інший
  • Розширені сценарії для комплексного тестування робочих процесів у листоноші

advanced scripting complex testing workflows postman

Спробуйте Наш Інструмент Для Усунення Проблем

Дізнайтеся про розширені сценарії поштар для складних робочих процесів тестування:

У цьому підручнику ми побачимо кілька основних прикладів використання Advanced Scripting with Postman, що дозволить нам запускати складні робочі процеси тестування.

Ми обговоримо такі приклади, як передача даних з одного запиту на інший, ланцюжок запитів, тобто контроль порядку виконання запитів усередині колекції листоноші тощо.

найкраще безкоштовне сканування та ремонт комп'ютера

=> Прочитайте серію навчальних курсів Easy Postmar.

POSTMAN Advanced Scripting

Що ви дізнаєтесь:

Передача даних між запитами у листоноші

Передача даних між запитами є розширенням використання різних типів змінних Поштальєна. Не рідкість, коли запит API залежить від даних відповіді попереднього запиту.

Для побудови такого роду можливостей, використовуючи Postman, ми можемо просто використовувати змінні Postman для встановлення значення залежно від відповіді, отриманої від попереднього або попереднього запитів.

Ось відеоурок:

Давайте розглянемо приклад, щоб проілюструвати це.

Ми будемо використовувати той самий API https://reqres.in з 2 кінцевими точками, тобто зареєструвати користувача та отримати дані про користувача.

Ми будемо використовувати значення ідентифікатора користувача, що повертається з реєструючої кінцевої точки, і використовуватимемо його для отримання методу інформації про користувача. Це буде досягнуто шляхом збереження значення userId у змінній середовища та використанні цієї змінної середовища у наступному запиті.

Зверніть увагу, що всі такі сценарії будуть частиною вкладки «Тести» консолі конструктора запитів «Листоноша».

Давайте подивимося, як буде виглядати сценарій:

# 1) Для реєстрації кінцевої точки користувача відповідь цього API буде виглядати так, як показано нижче.

{ 'id': 4, 'token': 'QpwL5tke4Pnpja7X4' }

Отримати дані з відповіді JSON
Тепер, щоб виконати запит GET, використовуючи ідентифікатор користувача з відповіді, нам потрібно отримати значення id із наведеної вище відповіді. Ми використаємо наведений нижче сценарій для зберігання значення ідентифікатора з цього JSON у змінну середовища з іменем ідентифікатор користувача.

var jsonData = pm.response.json(); pm.environment.set('userId',jsonData.id)

З наведеним вище сценарієм значення ідентифікатора тепер зберігатиметься у змінній середовища userId, і те саме може бути використано під час виконання кінцевої точки запиту користувача GET.

# два) Таким чином, запит користувача GET буде виглядати, як показано нижче.

https://reqres.in/api/users/{(userId}}

Після виконання першого запиту він отримає значення UserID з відповіді та оновить значення змінної середовища, щоб його можна було використовувати в інших запитах.

Запит ланцюжка в листоноші

Спершу спробуємо зрозуміти базовий випадок використання ланцюжків запитів, а потім ми глибше вивчимо, як ми можемо досягти ланцюжка запитів, використовуючи Postman.

Розглянемо сценарій потоку входу веб-сайту електронної комерції та перевіримо зареєстрованого користувача. Тепер, щоб користувач ввійшов, він або вона повинні спочатку зареєструватися на сайті, і лише тоді він зможе увійти. Це порядок, в якому фактичний сайт мобільного додатка виконує виклики API.

Подивіться на це з точки зору інтеграційного тесту. Для тестування API спочатку нам потрібно:

  • Зателефонуйте до реєстраційної кінцевої точки API, щоб користувач успішно зареєструвався.
  • Потім зателефонуйте кінцевій точці входу та підтвердьте деталі зареєстрованого користувача.

З Поштарем контроль за порядком виконання запитів не є прямим. Порядок виконання за замовчуванням - зверху вниз, тобто порядок, в якому запити оголошуються або створюються у колекції Поштовець.

Ланцюжок запитів або порядок виконання запиту змінюється за допомогою наступного сценарію:

postman.setNextRequest({{RequestName}});

Тут важливо зауважити, що цей сценарій ланцюжка запитів потрібно додати до сценарію попереднього запиту чи сценарію після запиту (або на вкладку тестів у конструкторі запитів листоноші), який запускає робочий процес після завершення виконання запиту.

Тут {{RequestName}} - це фактичне ім’я запиту, яке налаштовано або встановлено у колекції листонош.

Давайте налаштуємо колекцію Postman з 4 різними запитами, щоб проілюструвати концепцію ланцюжка запитів. Створіть нову колекцію з 4 запитами (Ми будемо використовувати той самий API https://reqres.in для ілюстрації).

4 запити в колекції будуть такими, як показано нижче:

# 1) POST запит на реєстрацію користувача ( https://reqres.in/api/register ) із зразком тексту JSON із полями, що містять електронну адресу та пароль, як показано нижче.

{ 'email': 'eve.holt@reqres.in', 'password': 'pistol' }

# два) Запит POST із кінцевою точкою входу ( https://reqres.in/api/login ) з тим самим тілом запиту, що і вище.

# 3) ОТРИМАТИ запит за допомогою userID 4.

Робочий процес, який ми спробуємо досягти, такий:

Реєстрація (POST) -> Інформація про користувача (GET) -> Вхід (POST)

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

Ланцюжок запитів листоноші

Зверніть увагу, що запити іменовані як Зареєструвати користувача, Отримати користувача та Користувача для входу відповідно. Важливо, щоб ці імена запитів були точно і правильно вказані в сценарії, інакше робочий процес застрягне.

Подивимось, як зараз виглядають сценарії.

# 1) POST запит на реєстрацію.

postman.setNextRequest('Login User');

Зареєструвати користувача

# два) Запит POST для входу.

postman.setNextRequest('Get User');

Запит користувача для входу

# 3) ОТРИМАТИ запит, щоб отримати дані про користувача. Тут важливо, щоб ми не хотіли, щоб щось сталося після цього запиту. Якщо ми не додамо сюди жодного сценарію робочого циклу, колекція Поштовик призначена для відновлення наступного запиту в логічному порядку або за замовчуванням.

Таким чином, припустимо, що початковий порядок запитів у колекції такий Зареєструйтесь, отримайте користувача і Увійти і наш робочий процес на Отримати користувача оскільки елемент управління не знає, який запит перейти далі, він перейде до наступного логічного запиту, який є Увійти і в кінцевому підсумку призведе до нескінченного циклу.

Щоб запобігти такій ситуації, корисно припинити робочий процес, використовуючи

postman.setNextRequest(null)

Отримати користувача

Всякий раз, коли вищезазначений сценарій зустрічається під час виконання колекції, виконання робочого циклу зупиняється, а бігун колекції припиняється.

У випадках, коли є циклічні посилання на наступний запит, бігун колекції застряє у нескінченному циклі, що спричинить витік пам'яті рано чи пізно.

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

Іншими словами, перший запит, який потрібно запустити як частину робочого циклу, також повинен бути першим запитом у колекції або папці колекції, так що виконання робочого процесу починається з першого запиту, який також є першим запитом робочого процесу .

Розширений ланцюжок робочих процесів з листоношею

Наведений вище приклад, який ми обговорювали, є скоріше лінійним робочим процесом, де ми щойно налаштували робочий процес між набором запитів в одній колекції. Той самий прийом також може бути використаний для повторення запиту кілька разів на основі деяких значень відповіді або змінних середовища.

Розгляньте інтеграційний тест для програми кошика для покупок, де вам потрібно протестувати сценарій, коли користувач шукає товар і додає його в кошик, і повинен виконати одну і ту ж операцію 5 разів, тобто до тих пір, поки в кошику не буде 5 позицій, а потім нарешті замовлення.

Отже, якби ви писали лінійний потік для такого роду тесту, ви б повторювали окремі запити в колекції, і по суті колекція мала б 5 запитів на пошук товару, і 5 запитів на додавання товарів у кошик та 1 запит на оплату.

Завдяки цій функціональності робочого циклу ми можемо уникнути повторення одних і тих самих запитів у колекції та використовувати робочі процеси для циклу між запитами.

Давайте побачимо послідовність потоків для такого сценарію (тоді це можна використовувати / створити за допомогою робочого процесу Postman разом із комбінацією змінних середовища).

різниця між тестом і планом тесту

Складний потік вимог

Також є цікавий приклад використання робочого циклу Postman для створення списку відтворення Spotify. Посилання тут для отримання додаткової інформації.

Важливі поради

Нижче наведено кілька важливих порад, які слід пам’ятати під час роботи над побудовою робочих процесів.

  1. Під час запуску колекції, якщо для кількох запитів не встановлено postment.setNextRequest, виконання продовжується у порядку збору за замовчуванням. Таким чином, зазвичай рекомендується мати Postman.setNextRequest в усіх запитах або в жодному з них.
  2. При запуску з колекціями, якщо в колекції є папки, Postman.setNextRequest можна використовувати лише для запитів, що належать до однієї папки, тобто вибір запиту не може виходити за межі поточної папки.
  3. Postman.setNextRequest - це останній оператор, який виконується в сценарії після-запиту або попереднього запиту, незалежно від того, де і в якому порядку він згадується.

У випадку, коли для setNextRequest знайдено кілька значень, ефективним є те, про яке йдеться в останньому.

Висновок

У цьому підручнику ми розглянули декілька розширених тем сценаріїв, таких як комбінування середовища та локальних змінних для передачі даних між різними запитами в Поштальєні, і як ми можемо контролювати порядок виконання запитів за допомогою ланцюжка запитів Поштальона, що дозволяє розширені можливості, такі як циклічне та розгалуження.

Це чудова функція імітувати поведінку програми таким чином, щоб вона взаємодіяла з різними API, і корисно писати наскрізні робочі процеси, використовуючи тести інтеграції з кінцевими точками API.

=> Ознайомтесь з Посібником з навчання ідеального листоноші тут.

Рекомендована література

^