Освоєння тестування REST API

Автор: Андрій Шальнев

Оригінал публікації: http://quality-lab.ru/rest-api-testing/

У цій статті я хочу поділитися досвідом освоєння тестування (в т. Ч. Автоматизації) на рівні API (Application Programming Interface - інтерфейс програмування додатків, інтерфейс прикладного програмування). Сподіваюся, що пропонований матеріал буде представляти інтерес для всіх, хто раніше проводив тестування через графічний інтерфейс і ще не має досвіду роботи з http-запитами.

Трохи про REST API і SOAP API

Варто зазначити, що на сьогоднішній день є два основні підходи до побудови програмного інтерфейсу веб-додатків: REST (RESTful) API і SOAP API:

• REST (від англ. Representational State Transfer - «передача стану уявлення») забезпечує спілкування між клієнтом (як правило, це браузер) і сервером за допомогою звичайних HTTP-запитів (GET, POST, PUT, DELETE і т. Д), передаючи інформацію від клієнта в параметрах самих запитів, інформацію від сервера - в тілі відповіді (який може бути, наприклад, JSON-об'єктом або XML-документом). REST є архітектурним стилем, а не стандартом.
• SOAP (від англ. Simple Object Access Protocol - простий протокол доступу до об'єктів, аж до специфікації 1.2) характеризується використанням HTTP (S) протоколом лише як транспорту (найчастіше, методом POST). Всі деталі повідомлень (в обидві сторони - від клієнта до сервера і назад) передаються в стандартизованном XML-документі. SOAP може працювати і з іншими протоколами прикладного рівня (SMTP, FTP), але частіше за все він застосовується поверх HTTP (S). SOAP є протоколом і має специфікацію .

Якщо уподібнити HTTP-запит паперовому носієві, то можна сказати, що REST API в більшості випадків передає прості записки, а час від часу - лист в конверті (можливо, написавши при цьому частина послання і на самому конверті). У свою чергу, SOAP API передає всі інструкції в докладному листі стандартного виду, використовуючи конверт (одиничний HTTP-запит) лише як засіб доставки. Для кращого розуміння різниці підходів я рекомендую читачеві подивитися наступну інфографіку .

У статті мова йтиме про REST API, так як цей підхід є більш поширеним через свою відносну простоту і зручності для розробників. SOAP API переважно характерний для великих корпоративних (enterprise) систем.

Чим робота з API може бути корисна тестувальника?

Для початку спробуємо зрозуміти, навіщо взагалі тестувальника освоювати щось на такому рівні. Здавалося б, програмні інтерфейси - це територія розробників. Нижче ми розглянемо вигоди використання тестування API.

Вигода перша: точна локалізація.
Уміння працювати з API дозволяє краще розуміти і точніше описувати виникли помилки. Припустимо, ви відкриваєте якусь сторінку сайту і бачите в інтерфейсі повідомлення про помилку. Чим конкретно вона викликана? Наскільки вона серйозна? Чи може вона вплинути на інших частинах системи? Нам буде набагато простіше відповісти на ці питання, якщо ми зможемо зрозуміти, яку саме функцію не вдалося виконати системі. Повідомлення в графічному інтерфейсі не завжди дозволяють оцінити цю залежність.

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

Більш того - численні дії в браузері часто є причиною помилкових «падінь» автоматизованих тестів, яким на рівні GUI властива «крихкість». Одне неуспішне натискання кнопки може привести до необхідності повторення або всього тесту, або якийсь його частини. Сформувавши запит програмно або відтворивши його за допомогою спеціальних інструментів (про це трохи пізніше), ми можемо істотно скоротити час перевірки.

Вигода третя: можливість відтворювати тести на великих наборах вхідних даних.
Для деяких проектів важливо проводити тести з великою кількістю різноманітних наборів вхідних даних, відокремлених від коду самого тесту і винесених в окремий файл. У цьому випадку один і той же сценарій може повторюватися багато разів для різних значень. Цю методологію (так звану Data Driven Testing ) Складно реалізувати через графічний інтерфейс з прийнятною швидкістю і стабільністю. Навпаки, на рівні http-запитів це робиться дуже швидко і з набагато більш високою надійністю.

Вигода четверта: можливість брати участь в проектах, де робота з API є вимогою тест-дизайну.

Сам тест-дизайн проекту може виявитися таким, що деяка частина тестів повинна буде проводитися тільки через програмні інтерфейси (наприклад, якщо на проекті реалізована концепція « піраміди тестування », При якій лише деякі тести використовують графічний інтерфейс). Також варто відзначити, що все більшої популярності набирає архітектура мікросервісов, коли додаток є не «монолітним», а фактично являє собою набір самостійних додатків, які обмінюються даними. І в цьому випадку тестування API стає особливо затребуваним, так як саме воно дозволяє в повній мірі переконатися в правильності інтеграції окремих сервісів і в дотриманні логіки функціонування системи в цілому. Невміння працювати з програмними інтерфейсами істотно обмежує можливість вашої участі в таких проектах.

Практичні кроки до освоєння роботи з REST API сайту

Отже, ви вирішили освоїти роботу з програмним інтерфейсом вашого сайту. З чого ж почати?

Крок 1: відкрийте Інструментарій розробника програмного забезпечення в браузері.
Відкрийте Інструментарій розробника програмного забезпечення (developer tools) в браузері (наприклад, в Mozilla Firefox і Google Chrome просто натисніть F12) і перейдіть у вкладку, в якій відбивається мережева активність (Network, Net, Мережа і т. Д.)

Здійснюйте звичайні дії в браузері і спостерігайте за результатом. Перше, що кидається в очі, - це величезна кількість запитів навіть при завантаженні однієї сторінки: для отримання кожного зображення, стилів, шрифтів, структури сторінки, скриптів. При використанні AJAX (Від англ. Asynchronous Javascript and XML - асинхронний JavaScript і XML, підхід до побудови призначених для користувача інтерфейсів веб-додатків, що полягає в «фоновому» обміні даними браузера з веб-сервером) кількість запитів може збільшуватися, навіть якщо ви не робите ніяких активних дій .

Крок 2: сховайте запити, які не відносяться до логіки роботи.
Що ж робити з величезною кількістю запитів? Як вибрати ті, які для нас корисні? Спробуйте застосувати текстовий фільтр. Багато запити, які стосуються логіці взаємодії клієнта і сервера (тобто, до API), можуть містити в своїх URL фрагмент, який вказує на це (наприклад, «api / rest»). Якщо ви виявили такий фрагмент - введіть його в пошуковий рядок DevTools. Інструментарій розробника програмного забезпечення в браузері також дозволяють виділити запити певного типу: XHR, JS, CSS, Images і т. Д.

Виберіть XHR (XMLHttpRequest) - це інтерфейс мови JavaScript, що використовується для конструювання запитів, що мають тіло. Зазвичай саме цей інтерфейс використовується для звернення до API. Ви можете зіткнутися з великою кількістю однотипних запитів, породжуваних різними системами моніторингу (наприклад, yandex.webvisor). Їх можна приховати, застосувавши негативний фільтр (наприклад, «-yandex» для Chrome), навіть якщо ви не знаєте точно, що саме ці запити роблять. Однотипні і часто повторювані запити, як правило, відносяться до моніторингу сайту, а не до логіки здійснюваних користувачем дій.

Перегляньте уважно залишилися після застосування фільтра запити і постарайтеся виявити ті, які відносяться саме до логіки дій. У разі необхідності зверніться за роз'ясненнями до розробників. Якщо вам доступна документація, в якій описуються endpoint-и сервісів вашого проекту (т. Е. Адреси, до яких звертаються запити, які стосуються API), - вивчіть її. Нижче я буду розглядати варіант, коли докладної документації або відповідних доступів у вас немає.

Досить часто за адресою endpoint-а можна здогадатися, за що саме відповідає запит до даного сервісу. Наприклад, адреса, що містить фрагмент «api / rest / createContract», швидше за все, використовується для створення договору, «api / rest / buildInfo» - для виведення інформації про версії, встановленої в поточний момент, а «api / rest / news / search »- для пошуку новин. Якщо важко «виловити» потрібний запит в загальній масі (а запитів до API теж може бути чимало) - очистіть історію запитів перед вчиненням цікавить вас дії. Досить швидко ви навчитеся бачити потрібні запити і зіставляти їх з діями в інтерфейсі.

Натисніть на картинку, щоб збільшити зображення

Крок 3: проведіть більш детальний аналіз структури запитів.
Зверніть увагу на те, що частина запитів передає інформацію тільки в запрошенном URL-е. В першу чергу, це GET-запити, які призначені для отримання певного вмісту або запуску процесу. Класичний приклад - запит на текстовий пошук. Його URL може виглядати як «https://anysite.ru/search?keywords=my_query&itemsperpage=20», де «../search» - адреса пошукового сервісу, «keywords = ...» - текст запиту, «itemsperpage» - параметр, відповідальний за кількість результатів, що виводяться на одній сторінці.

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

URL: POST https://www.youtube.com/feed_ajax?action_pause_watch_history=1 HTTP / 1.1
Request headers: додаткова інформація, в т. Ч. Cookies.
Message Body:
session_token = QUFFLUhqbER0TE5idlp2MngybFh1ZUUyblYtaGlmLVhmZ3xBQ3Jtc0tta1J5W
m9uZHpVTW9oWHIzOWdIblkzVk1wVTNFQS1aS0pfNG85OWw3Sk14U2
В цьому випадку суть необхідного дії передається в URL-е (action_pause_watch_history = 1), а інформація про користувача - в тілі запиту (session_token).

На структуру тіла запитів і надходження відповідей не накладається обмежень. Це може бути як просто набір пар поле / значення (т. Н. Form Data, як в прикладі вище session_token / значення), так і документ в зручному для розробника форматі (JSON, XML або якомусь іншому).

Проаналізуйте приходять відповіді (вкладка Response) і їх коди. Крім усього іншого, коди відповідей, як правило, несуть корисну інформацію і повідомляють про логіку того, що відбувається. Більшість запитів мають код відповіді «200 OK», який повідомляє про те, що операція пройшла успішно. У разі виникнення помилки коди починатимуться на 4 (помилка на стороні клієнта) або на 5 (помилка на стороні сервера). Наприклад, такі всім відомі помилки 404 ( «клієнт запросив неіснуючий ресурс») і 500 ( «внутрішня помилка сервера»). Зверніть увагу, що браузери надають можливість перегляду подробиць запитів / відповідей як в зручному форматі ( «parsed» в Google Chrome, «pretty print» в Mozilla Firefoх), так і в «сирому» вигляді ( «source»). Звичайно, для розуміння простіше «parsed» / «pretty print», але в тому випадку, коли вам необхідно скопіювати частину запиту, краще переключитися в режим «source».

Натисніть на картинку, щоб збільшити зображення

Натисніть на картинку, щоб збільшити зображення

Крок 4: відтворіть запити.

Отже, ви бачите потрібні запити і розумієте, які саме параметри вони передають і з якою метою. Тепер можна спробувати самостійно змінювати значення параметрів для отримання потрібних дій. Яким чином можна відтворити запити зі зміненими параметрами? Найпростіший спосіб - створювати GET-запити, просто вводячи їх в адресний рядок браузера (по суті, адресний рядок - це інтерфейс командного рядка для відтворення GET-запитів). Але вам не вдасться зробити багато, обмежившись лише GET-методом.

Для розширення ваших можливостей використовуйте Fiddler або подібні до нього інструменти (наприклад, такі ). Ці програми перехоплюють весь мережевий трафік, дозволяючи переглядати, редагувати і відтворювати окремі запити. Вже на цьому рівні можна щось тестувати - наприклад, затвердження даних на стороні сервера. Якщо веб-клієнт в браузері не дозволив вам ввести деякі значення - в Fiddler-е ви сконструіруете запит самі. Такий спосіб може істотно прискорити перевірку великого набору даних для введення, особливо якщо зміна значень в браузері займає тривалий час.

В якості приємного бонусу я приведу невелику покрокову інструкцію по відтворенню запиту в Fiddler.

• Налаштуйте фільтрацію у вкладці Filters. Фільтрація можлива за багатьма параметрами, але мені видається, що один з найбільш зручних варіантів - відображати запити тільки для певного сайту (хоста) і тільки за умови, що адреса запиту містить певний фрагмент (т. Е. Має відношення до API).

Натисніть на картинку, щоб збільшити зображення

• Натисніть на Вас запит і перейдіть у вкладку Inspectors. У верхній частині виберіть варіант Raw - ви побачите, яким чином запит відображається в «сирому» вигляді. Скопіюйте текст запиту.

Натисніть на картинку, щоб збільшити зображення

• Перейдіть у вкладку Composer, виберіть у ній Scratchpad, вставте текст запиту.

Натисніть на картинку, щоб збільшити зображення

• Відредагуйте потрібні параметри, виділіть текст запиту повністю (це обов'язково) і натисніть Execute. Спостерігайте результат виконання запиту в головному вікні програми (переконайтеся, що запит в разі зміни параметрів проходить фільтри).

Натисніть на картинку, щоб збільшити зображення

Далі - автоматизація тестування REST API!

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

З іншого боку, механізм авторизації буває досить складним, його не завжди легко пройти тільки за допомогою запитів. Але і це не викликає особливих проблем в тому випадку, якщо API-тести інтегровані з тестами GUI. Потрібні cookie можна забрати в браузері, відкритому за допомогою Selenium (driver.manage (). GetCookieNamed ( «sessionId»). GetValue ()).

Для доступу до API за допомогою мови програмування потрібно бібліотека, яка працює з http-запитами. Для Java можу порекомендувати rest-assured, в своєму фреймворку я використовую саме її. Ця бібліотека зручна і популярна - у вас не виникає проблем ні з розумінням коду, ні з перебуванням документації, прикладів і обговорень. Rest-assured використовує синтаксис в стилі BDD (Behavior Driven Development - підхід до автоматизації тестування, прагне описувати код тестів мовою, близьким до природного) з характерними ключовими словами given / when / then:

protected ExtractableResponse postRequest (String requestPayload, String endpoint, int expectedStatus) {
return
given ().
auth (). basic ( "login", "password").
cookies ( "sessionId", session).
contentType (ContentType.JSON).
body (requestPayload).
relaxedHTTPSValidation ().
when ().
post (endpoint).
then ().
statusCode (expectedStatus).
body (containsString ( "www")).
extract ();
}

Блок given описує передумови, такі як авторизація та параметри запиту. Зверніть увагу: окремо можна провести базову http-авторизацію (auth (). Basic ( «login», «password»)) і призначену для користувача авторизацію, передавши потрібні куки (cookies ( «sessionId», session)). Дуже зручно використовувати опцію relaxedHTTPSValidation (), щоб уникнути клопоту з підтвердженням сертифікатів. Блок when () описує потрібні дії - запит якого типу і на яку адресу слід відправити. Блок then () включає перевірки, які необхідно провести (їх може бути декілька одночасно).

Наприклад, ви можете перевірити, чи відповідає статус відповіді очікуваному (statusCode (expectedStatus)) і містить тіло відповіді певний фрагмент тексту (body (containsString ( «www»))). Команда extract () дозволяє отримати відповідь і використовувати його, наприклад, для отримання певних значень.

Це можна зробити наступним чином:

ExtractableResponse response = postRequest (session, payload, endpoint, 200);
int numberOfResults = response.path ( "results.total");

Тут команда path ( «results.total») дозволяє вітягті значення, вікорістовуючі JsonPath або XPath (в залежності від того, в якому форматі Надано відповідь). Зверніть увагу, что віклікається метод postRequest визначили в моєму фреймворку, а не в Бібліотеці rest-assured. Якщо вам важливо просто отримати тіло відповіді для подальших перевірок, а блок then не змінюється, то зручніше за все буде для кожного типу запитів (get, post, delete і т. Д.) Створити свій допоміжний метод і не прописувати given / when / then кожен раз. Для роботи з мовою Python використовується популярна бібліотека requests.

Варто відзначити, що і Java, і Python мають засоби роботи з http в числі стандартних можливостей, але я неодноразово стикався з думкою, що вони не дуже зручні. Якщо ви не плануєте писати тести з використанням мови програмування, то вам, швидше за все, підійде інструмент Postman - він дозволяє відтворювати і зберігати запити, а також вибудовувати з них тести.

Висновок

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

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

Обговорити в форумі.