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

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

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

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

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

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

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

Тесты в этом пакете обычно занимают больше времени, поэтому мы помещаем большую часть нашего охвата в Suite 1. Это говорит о том, что в этом пакете по-прежнему остается четкое значение, так как наши макеты в Suite 1 не могут вести себя как настоящие сервисы,

Frisby - это платформа тестирования API REST, построенная на node.js и Jasmine, которая упрощает, быстро и весело тестирует конечные точки API 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}

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

Свободный уровень Runscope поддерживает до 10K запросов в месяц.

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

Я использовал SOAP UI для функционального и автоматизированного тестирования. Интерфейс SOAP позволяет запускать тесты одним нажатием кнопки. Существует также spring тестирование контроллеров, созданная Ted Young. Я использовал эту статью для создания тестов модулей Rest в нашем приложении.

Вы также можете использовать Restored Assurance. Для демонстрации с образцом script обратитесь к http://artoftesting.com/automationTesting/restAPIAutomationGetRequest.html

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

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

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

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

Я реализовал множество случаев автоматизации на основе REST Assured, jave DSL для тестирования обслуживания. https://code.google.com/p/rest-assured/

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

До этого я попробовал SOAPUI и имел некоторые проблемы со свободной версией. Плюс случаи в файлах xml, которые трудно продлить и повторно использовать, просто мне не нравится

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

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

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

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