Автоматизированное тестирование REST Api [закрыто]

Я хотел бы написать пакет автоматического тестирования для REST API. По мере завершения работы над новыми службами мы хотим убедиться, что все ранее созданные службы работают должным образом. Есть какие-нибудь предложения по поводу лучших инструментов для этого? Я знаю, что существуют такие инструменты, как Apigee, которые позволяют вам тестировать 1 сервис за раз, но мы хотели бы иметь возможность тестировать все сервисы одним нажатием кнопки.

В рамках моей работы мы недавно собрали несколько наборов тестов, написанных на Java, для тестирования некоторых созданных нами RESTful API. Наши Сервисы могут вызывать другие API RESTful, от которых они зависят. Мы разделили его на два люкса.

• Suite 1 - тестирование каждой службы по отдельности
  • Имитируйте любые одноранговые службы, от которых зависит API, используя restito . Другие альтернативы включают rest-driver , wiremock и betamax .
  • Тестирует сервис, который мы тестируем, и все макеты запускаются в одной JVM.
  • Запускает сервис в Jetty

Я определенно рекомендую это сделать. У нас это сработало очень хорошо. Основные преимущества:

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

• Люкс 2 - Полный от начала до конца
  • Suite работает в полной среде, развернутой на нескольких машинах
  • API, развернутый на Tomcat в среде
  • Одноранговые сервисы - это реальные полные развертывания в реальном времени

Этот пакет требует, чтобы мы настраивали данные в одноранговых службах, что означает, что для написания тестов обычно требуется больше времени. Насколько это возможно, мы используем клиентов REST для настройки данных в одноранговых службах.

Написание тестов в этом наборе обычно занимает больше времени, поэтому мы помещаем большую часть нашего обзора в Suite 1. При этом все еще есть очевидная ценность в этом наборе, поскольку наши макеты в Suite 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 UI для функционального и автоматизированного тестирования. Интерфейс SOAP позволяет запускать тесты одним нажатием кнопки. Также существует страница тестирования контроллеров Spring, созданная Тедом Янгом. Я использовал эту статью для создания модульных тестов Rest в нашем приложении.

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

Вариант, который подходит для API, реализованных с помощью Node.JS / Express, - это использование мокко для автоматического тестирования. Помимо модульных тестов, легко писать функциональные тесты для API, разделенных на разные наборы тестов. Вы можете автоматически запустить сервер API в локальной тестовой среде и настроить локальную тестовую базу данных. Используя make, npm и сервер сборки, вы можете создать цель «make test» и инкрементную сборку, которая будет запускать весь набор тестов каждый раз, когда фрагмент кода отправляется в ваш репозиторий. Для по-настоящему привередливого разработчика он даже сгенерирует хороший отчет о покрытии кода HTML, показывающий, какие части вашей кодовой базы покрываются тестами, а какие нет. Если это звучит интересно, вот сообщение в блоге, в котором представлены все технические детали.

Если вы не используете узел, то какой бы ни была структура модульного тестирования де-факто для языка (jUnit, cucumber / capybara и т. Д.) - посмотрите на его поддержку для раскрутки серверов в локальной тестовой среде и выполнения HTTP-запросов. Если это большой проект, то усилия по автоматическому тестированию API и постоянной интеграции окупятся довольно быстро.

Надеюсь, это поможет.

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

Уровень бесплатного пользования Runscope поддерживает до 10 000 запросов в месяц.

Отказ от ответственности: я являюсь сторонником разработчиков Runscope.

Я реализовал много вариантов автоматизации на основе REST Assured, jave-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 или проверки схемы. После того, как тесты запланированы, вы можете получать уведомления, которые будут уведомлять вас, как только конкретный тест не проходит проверку или выходит за пределы установленных диапазонов для времени ответа или размера ответа.

Я использовал классы HTTP TestNG и Apache для создания своей собственной тестовой среды REST API. Я разработал эту концепцию после двух лет работы в Selenium.

Все то же самое, за исключением того, что вы должны использовать классы HTTP Apache вместо классов Selenium.

Попробуйте, это действительно мило и хорошо, у вас есть все возможности для настройки своей тестовой среды в соответствии с вашими возможностями.