Автоматизоване тестування для REST Api [закрито]

Я хотів би написати автоматизований пакет тестування для REST API. Оскільки ми завершуємо нові послуги, ми хотіли б перевірити, чи всі створені раніше служби працюють належним чином. Будь-які пропозиції щодо найкращих інструментів для цього? Я знаю, що існують такі інструменти, як Apigee, які дозволяють тестувати по 1 службі за раз, але ми хотіли б спосіб перевірити всі служби одним натисканням кнопки.

У своїй роботі ми нещодавно зібрали кілька тестових наборів, написаних на Java, для тестування деяких RESTful API, які ми створили. Наші служби можуть викликати інші RESTful API, від яких вони залежать. Ми розділили його на два апартаменти.

• Люкс 1 - Тестування кожної послуги ізольовано
  • Знущайтеся над будь-якими службами однолітків, від яких API залежить від використання restito . Інші альтернативи включають драйвер відпочинку , дротокети та бетамакс .
  • Тестує службу, яку ми тестуємо, і всі припущення працюють в одному JVM
  • Запускає послугу на пристані

Я точно рекомендую це зробити. Це дуже добре у нас спрацювало. Основними перевагами є:

• Служби однолітків висміюються, тому вам не потрібно виконувати складні налаштування даних. Перед кожним тестом ви просто використовуєте restito, щоб визначити, як ви хочете, щоб поводились однорангові служби, як це було б з класами в модульних тестах з Mockito.
• Ви можете попросити знущаних служб, якщо їх викликали. Ви не можете зробити ці твердження так легко за допомогою реальних служб однолітків.
• Набір надзвичайно швидкий, оскільки знущаються служби пропонують попередньо підготовлені відповіді в пам'яті. Тож ми можемо отримати гарне покриття, не вистачаючи віку для роботи.
• Набір надійний і повторюваний, оскільки його ізольований у власному JVM, тому не потрібно турбуватися про те, що інші люкси / люди одночасно працюють із загальним середовищем і викликають невдачі тестів.

• Люкс 2 - повний кінець у кінець
  • Suite працює проти повного середовища, розгорнутого на декількох машинах
  • API розгорнуто на Tomcat у середовищі
  • Служби однолітків є справжніми повними розгортаннями "як живі"

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

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

Frisby - це програма тестування REST API, побудована на node.js та Jasmine, яка робить тестування кінцевих точок API простим, швидким та цікавим. http://frisbyjs.com

Приклад:

var frisby = require('../lib/frisby');

var URL = 'http://localhost:3000/';
var URL_AUTH = 'http://username:password@localhost:3000/';

frisby.globalSetup({ // globalSetup is for ALL requests
  request: {
    headers: { 'X-Auth-Token': 'fa8426a0-8eaf-4d22-8e13-7c1b16a9370c' }
  }
});

frisby.create('GET user johndoe')
  .get(URL + '/users/3.json')
  .expectStatus(200)
  .expectJSONTypes({
    id: Number,
    username: String,
    is_admin: Boolean
  })
  .expectJSON({
    id: 3,
    username: 'johndoe',
    is_admin: false
  })
  // 'afterJSON' automatically parses response body as JSON and passes it as an argument
  .afterJSON(function(user) {
    // You can use any normal jasmine-style assertions here
    expect(1+1).toEqual(2);

    // Use data from previous result in next test
    frisby.create('Update user')
      .put(URL_AUTH + '/users/' + user.id + '.json', {tags: ['jasmine', 'bdd']})
      .expectStatus(200)
    .toss();
  })
.toss();

З цієї причини я співпрацював з одним зі своїх колег, щоб запустити фреймворк PyRestTest: https://github.com/svanoort/pyresttest

Хоча ви можете працювати з тестами на Python, звичайний формат тесту - YAML.

Зразок тестового набору для базової програми REST - перевіряє, чи API відповідає правильно, перевіряючи коди стану HTTP, хоча ви також можете зробити так, щоб він перевіряв тіла відповідей:

---
- config:
    - testset: "Tests using test app"

- test: # create entity
    - name: "Basic get"
    - url: "/api/person/"
- test: # create entity
    - name: "Get single person"
    - url: "/api/person/1/"
- test: # create entity
    - name: "Get single person"
    - url: "/api/person/1/"
    - method: 'DELETE'
- test: # create entity by PUT
    - name: "Create/update person"
    - url: "/api/person/1/"
    - method: "PUT"
    - body: '{"first_name": "Gaius","id": 1,"last_name": "Baltar","login": "gbaltar"}'
    - headers: {'Content-Type': 'application/json'}
- test: # create entity by POST
    - name: "Create person"
    - url: "/api/person/"
    - method: "POST"
    - body: '{"first_name": "Willim","last_name": "Adama","login": "theadmiral"}'
    - headers: {Content-Type: application/json}

Я використовував інтерфейс SOAP для функціонального та автоматизованого тестування. Інтерфейс SOAP дозволяє запускати тести натисканням кнопки. Також є сторінка тестування контролерів пружин, створена Тедом Янгом. Я використав цю статтю для створення модульних тестів «Відпочинок» у нашому додатку.

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

Варіант, який підходить для API, реалізованих за допомогою Node.JS / Express, - це використовувати мокку для автоматизованого тестування. На додаток до модульних тестів, легко писати функціональні тести щодо API, розділених на різні тестові набори. Ви можете автоматично запустити сервер API у локальному тестовому середовищі та налаштувати локальну тестову базу даних. Використовуючи make, npm та сервер збірки, ви можете створити ціль "make test" та інкрементальну збірку, яка буде запускати весь набір тестів кожного разу, коли фрагмент коду надходить у ваше сховище. Для справді вибагливого розробника він навіть створить приємний звіт про покриття коду HTML, який показує, які частини вашої кодової бази охоплені тестами чи ні. Якщо це звучить цікаво, ось публікація в блозі, яка містить усі технічні деталі.

Якщо ви не використовуєте node, то яким би не був дефакто-модуль модульного тестування для мови (jUnit, огірок / капібара тощо) - подивіться на його підтримку для обертання серверів у локальному тестовому середовищі та запуску HTTP-запитів. Якщо це великий проект, зусилля з метою автоматизованого тестування API та постійної роботи з інтеграцією окупляться досить швидко.

Сподіваюся, що це допомагає.

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

Безкоштовний рівень Runscope підтримує до 10 тис. Запитів на місяць.

Застереження: Я є адвокатом розробника Runscope.

Я реалізував багато випадків автоматизації на основі REST Assured, Java DSL для тестування спокійного сервісу. https://code.google.com/p/rest-assured/

Синтаксис простий, він підтримує json та xml. https://code.google.com/p/rest-assured/wiki/Usage

До цього я пробував SOAPUI і мав проблеми з безкоштовною версією. Плюс справи у файлах xml, які важко розширити та повторно використати, просто мені не подобається

Ви також можете скористатися бібліотекою Rest Assured. Демо-версію зі зразком сценарію див. На веб-сайті http://artoftesting.com/automationTesting/restAPIAutomationGetRequest.html

Автоматизація тестування API, до одного разу на хвилину, - це послуга, доступна через theRightAPI . Ви створюєте свої тестові сценарії та виконуєте їх. Як тільки ці тести виконають те, що ви очікуєте від них, ви можете запланувати їх. Тести можна поєднати в ланцюжки для сценаріїв, які вимагають автентифікації. Наприклад, ви можете мати тест, який робить запит OAuth на Twitter, і створює спільний маркер, який потім може бути використаний будь-яким іншим тестом. Тести можуть також мати прикріплені критерії перевірки, щоб забезпечити коди статусу http, або навіть детальний огляд відповідей за допомогою перевірки JavaScript або схеми. Після того, як тести заплановані, ви зможете сповіщати вас, як тільки певний тест не пройде перевірку або не відповідає встановленому діапазону для часу відгуку або розміру відповіді.

Я використовував класи TestNG та Apache HTTP для створення власної тестової бази REST API, я розробив цю концепцію, працюючи в Selenium протягом двох років.

Все однаково, за винятком того, що ви повинні використовувати класи Apache HTTP замість класів Selenium.

спробуйте, це дійсно мило і добре, ви маєте всі можливості налаштувати свою тестову структуру на всі свої можливості.