Teste automatizado para REST Api [fechado]


84

Eu gostaria de escrever um conjunto de testes automatizados para uma API REST. Conforme concluímos os novos serviços, gostaríamos de verificar se todos os serviços criados anteriormente estão funcionando como esperado. Alguma sugestão sobre as melhores ferramentas a serem usadas para fazer isso? Eu sei que existem ferramentas como o Apigee que permitem que você teste 1 serviço por vez, mas gostaríamos de ter uma maneira de testar todos os serviços com o clique de um botão.


2
Você pode dar uma chance ao vREST . Ele tem testes de unidade e simulações.
Jangid

1
JMeter é a melhor ferramenta para teste de API REST - Adicionando este comentário para pessoas que estão procurando algumas etapas detalhadas para testar uma API REST usando JMeter. testautomationguru.com/how-to-test-rest-api-using-jmeter
vins

Nada supera o FRISBY - Apenas a ferramenta perfeita e mais poderosa para testes de API REST
Piyush Chordia

2
JMeter é um exagero, sem mencionar que tem uma interface de usuário horrível, apenas para testes funcionais básicos de uma API REST. Destina-se a testes de desempenho / carga.
Kevin M

2
JMeter está mais focado em testes de carga, talvez você deva verificar 12 Ótimas ferramentas de teste de serviço da Web para encontrar a melhor opção. Algumas das ferramentas desta lista, por exemplo SOAPUI ou HttpMaster , têm um suporte de automação bastante decente para terminais de API REST.
Joxi,

Respostas:


36

No meu trabalho, recentemente reunimos alguns conjuntos de testes escritos em Java para testar algumas APIs RESTful que construímos. Nossos serviços podem invocar outras APIs RESTful das quais dependem. Nós o dividimos em duas suítes.


  • Suite 1 - Testando cada serviço isoladamente
    • Zombe de quaisquer serviços de mesmo nível que a API dependa usando o restito . Outras alternativas incluem rest-driver , wiremock e betamax .
    • Testa o serviço que estamos testando e as simulações são executadas em uma única JVM
    • Lança o serviço no Jetty

Definitivamente, eu recomendaria fazer isso. Funcionou muito bem para nós. As principais vantagens são:

  • Os serviços de mesmo nível são simulados, então você não precisa realizar nenhuma configuração complicada de dados. Antes de cada teste, você simplesmente usa o restito para definir como deseja que os serviços de mesmo nível se comportem, assim como você faria com as classes em testes de unidade com o Mockito.
  • Você pode perguntar aos serviços de pares simulados se eles foram chamados. Você não pode fazer essas afirmações tão facilmente com serviços de pares reais.
  • O pacote é super rápido, pois os serviços simulados atendem a respostas predefinidas na memória. Assim, podemos obter uma boa cobertura sem que a suíte demore muito para funcionar.
  • A suíte é confiável e repetível, pois é isolada em sua própria JVM, então não há necessidade de se preocupar com outras suítes / pessoas mexendo em um ambiente compartilhado ao mesmo tempo em que a suíte está em execução e fazendo com que os testes falhem.

  • Suite 2 - De ponta a ponta
    • Suite é executado em um ambiente completo implantado em várias máquinas
    • API implantada no Tomcat no ambiente
    • Os serviços de mesmo nível são implantações completas reais 'em tempo real'

Este conjunto exige que façamos a configuração dos dados em serviços de pares, o que significa que os testes geralmente levam mais tempo para escrever. Tanto quanto possível, usamos clientes REST para fazer a configuração de dados em serviços de mesmo nível.

Os testes nesta suíte geralmente demoram mais para serem escritos, então colocamos a maior parte de nossa cobertura na Suite 1. Dito isso, ainda há um valor claro nesta suíte, pois nossos simuladores na Suite 1 podem não se comportar exatamente como os serviços reais.



25

Frisby é uma estrutura de teste de API REST construída em node.js e Jasmine que torna o teste de endpoints de API fácil, rápido e divertido. http://frisbyjs.com

Exemplo:

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();

Votei neste artigo, usei-o no meu trabalho diário e agora são todos frisbies sendo jogados por aí. Eu compartilhei sobre o mesmo em meu blog: cubicrace.com/2016/04/frisby-rest-api-automation-framework.html
Piyush Chordia


Frisby é fácil de começar e poderoso o suficiente para testar até mesmo fluxos de API avançados. Infelizmente, a saída do relatório deixa muito a desejar. As mensagens de erro quando a API está falhando são quase inúteis. O que é estranho, visto que a saída quando você executa os testes manualmente é muito boa. É uma vergonha.
Kasper Holdum

1
No caso de alguém tropeçar nisso da maneira que eu fiz, frisby não parece estar morto ainda, como um comentário mencionado acima. O git tem atualizações recentes. github.com/vlucas/frisby
S.Huston

21

Eu colaborei com um de meus colegas de trabalho para iniciar a estrutura PyRestTest por este motivo: https://github.com/svanoort/pyresttest

Embora você possa trabalhar com os testes em Python, o formato de teste normal é YAML.

Conjunto de testes de amostra para um aplicativo REST básico - verifica se as APIs respondem corretamente, verificando os códigos de status HTTP, embora você também possa fazer com que examine corpos de resposta:

---
- 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}

Com a autenticação, você adiciona abaixo a cada teste referenciado em github.com/svanoort/pyresttest/blob/master/quickstart.md com os cabeçalhos abaixo; - auth_username: "foobar" - auth_password: "secret"
expect_status


2

Um dos problemas de fazer testes automatizados para APIs é que muitas das ferramentas requerem que você tenha o servidor de API instalado e funcionando antes de executar seu conjunto de testes. Pode ser uma vantagem real ter uma estrutura de teste de unidade capaz de executar e consultar as APIs em um ambiente de teste totalmente automatizado.

Uma opção boa para APIs implementadas com Node.JS / Express é usar mocha para testes automatizados. Além dos testes de unidade, é fácil escrever testes funcionais nas APIs, separados em diferentes suítes de teste. Você pode iniciar o servidor API automaticamente no ambiente de teste local e configurar um banco de dados de teste local. Usando make, npm e um servidor de compilação, você pode criar um destino de "teste de make" e uma compilação incremental que executará todo o conjunto de testes sempre que um trecho de código for enviado ao seu repositório. Para o desenvolvedor realmente exigente, ele até gerará um bom relatório de cobertura de código HTML, mostrando quais partes de sua base de código são cobertas por testes ou não. Se isso parece interessante, aqui está uma postagem de blog que fornece todos os detalhes técnicos.

Se você não estiver usando o node, qualquer que seja a estrutura de teste de unidade de fato para o idioma (jUnit, cucumber / capivara, etc) - observe seu suporte para ativar servidores no ambiente de teste local e executar as consultas HTTP. Se for um projeto grande, o esforço para fazer o teste de API automatizado e a integração contínua funcionar será recompensado muito rapidamente.

Espero que ajude.


2

Runscope é um serviço baseado em nuvem que pode monitorar APIs da Web usando um conjunto de testes. Os testes podem ser programados e / ou executados por meio de web hooks parametrizados. Os testes também podem ser executados em centros de dados em todo o mundo para garantir que os tempos de resposta sejam aceitáveis ​​para a base de clientes global.

O nível gratuito do Runscope suporta até 10 mil solicitações por mês.

Isenção de responsabilidade: Eu sou um defensor do desenvolvedor Runscope.




0

A automação de teste de API, até uma vez por minuto, é um serviço disponível por meio da API Right . Você cria seus cenários de teste e os executa. Depois que esses testes fizerem o que você espera, você poderá agendá-los. Os testes podem ser 'encadeados' para cenários que requerem autenticação. Por exemplo, você pode ter um teste que faz uma solicitação OAuth ao Twitter e cria um token compartilhado que pode ser usado por qualquer outro teste. Os testes também podem ter critérios de validação anexados para garantir códigos de status http, ou até mesmo uma inspeção detalhada das respostas usando javascript ou validação de esquema. Uma vez que os testes são agendados, você pode ter alertas para notificá-lo assim que um teste particular falhar na validação ou se comportar fora dos intervalos estabelecidos para o tempo de resposta ou tamanho da resposta.


O link parece estar quebrado.
Rao

0

Usei as classes TestNG e Apache HTTP para construir minha própria estrutura de teste da API REST, desenvolvi esse conceito depois de trabalhar no Selenium por dois anos.

Tudo é o mesmo, exceto que você deve usar classes Apache HTTP em vez de classes Selenium.

experimente, é realmente fofo e bom, você tem todo o poder para personalizar sua estrutura de teste para todas as suas possibilidades.


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.