Test automatizzati per REST Api [chiuso]


84

Vorrei scrivere una suite di test automatizzati per un'API REST. Man mano che completiamo nuovi servizi, vorremmo verificare che tutti i servizi creati in precedenza funzionino come previsto. Qualche suggerimento sui migliori strumenti da utilizzare per ottenere questo risultato? So che esistono strumenti come Apigee che ti consentono di testare 1 servizio alla volta, ma ci piacerebbe un modo per testare tutti i servizi con il clic di un pulsante.


2
Potresti provare vREST . Ha sia test di unità che mock.
Pankaj Jangid

1
JMeter è lo strumento migliore per il test dell'API REST: aggiunta di questo commento per le persone che cercano alcuni passaggi dettagliati per testare un'API REST utilizzando JMeter. testautomationguru.com/how-to-test-rest-api-using-jmeter
vins

Niente batte FRISBY - Solo lo strumento perfetto e più potente per i test API REST
Piyush Chordia

2
JMeter è eccessivo, per non parlare del fatto che ha un'interfaccia utente orribile, solo per i test funzionali di base di un'API REST. È pensato per test di prestazioni / carico.
Kevin M

2
JMeter si concentra maggiormente sui test di carico, forse dovresti controllare 12 Great Web Service Testing Tools per trovare l'opzione migliore. Alcuni degli strumenti di questo elenco, ad esempio SOAPUI o HttpMaster , hanno un supporto di automazione abbastanza decente per gli endpoint dell'API REST.
Joxi

Risposte:


36

Nel mio lavoro abbiamo recentemente messo insieme un paio di suite di test scritte in Java per testare alcune API RESTful che abbiamo creato. I nostri servizi potrebbero richiamare altre API RESTful da cui dipendono. Lo abbiamo diviso in due suite.


  • Suite 1: testare ogni servizio in isolamento
    • Mock qualsiasi servizio peer che l'API dipende dall'utilizzo di restito . Altre alternative includono rest-driver , wiremock e betamax .
    • Verifica il servizio che stiamo testando e tutti i mock vengono eseguiti in un'unica JVM
    • Lancia il servizio in Jetty

Consiglio vivamente di farlo. Ha funzionato davvero bene per noi. I principali vantaggi sono:

  • I servizi peer vengono derisi, quindi non è necessario eseguire alcuna configurazione complicata dei dati. Prima di ogni test è sufficiente utilizzare restito per definire come si desidera che i servizi peer si comportino, proprio come faresti con le classi negli unit test con Mockito.
  • Puoi chiedere ai servizi peer derisi se sono stati chiamati. Non puoi fare queste affermazioni con la stessa facilità con i servizi di pari livello.
  • La suite è super veloce poiché i servizi fittizi forniscono risposte in memoria predefinite. Quindi possiamo ottenere una buona copertura senza che la suite impieghi un'età per funzionare.
  • La suite è affidabile e ripetibile poiché è isolata nella propria JVM, quindi non c'è bisogno di preoccuparsi che altre suite / persone si muovano con un ambiente condiviso mentre la suite è in esecuzione e causa il fallimento dei test.

  • Suite 2 - Full End to End
    • Suite funziona in un ambiente completo distribuito su più macchine
    • API distribuita su Tomcat nell'ambiente
    • I servizi peer sono implementazioni complete "live"

Questa suite richiede la configurazione dei dati nei servizi peer, il che significa che i test generalmente richiedono più tempo per la scrittura. Per quanto possibile, utilizziamo client REST per impostare i dati nei servizi peer.

I test in questa suite di solito richiedono più tempo per scrivere, quindi abbiamo messo la maggior parte della nostra copertura nella Suite 1. Detto questo, c'è ancora un chiaro valore in questa suite poiché i nostri mock in Suite 1 potrebbero non comportarsi esattamente come i servizi reali.



25

Frisby è un framework di test API REST basato su node.js e Jasmine che rende il test degli endpoint API facile, veloce e divertente. http://frisbyjs.com

Esempio:

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

Ho votato questo articolo, l'ho usato nel mio lavoro quotidiano e ora sono tutti i frisby che vengono lanciati in giro. Ho condiviso più o meno lo stesso sul mio blog: cubicrace.com/2016/04/frisby-rest-api-automation-framework.html
Piyush Chordia


Frisby è facile da usare e abbastanza potente da testare anche flussi API avanzati. Purtroppo l'output del report lascia molto a desiderare. I messaggi di errore quando l'API non funziona sono quasi al punto da essere inutili. Il che è strano dato che l'output quando esegui manualmente i test è abbastanza buono. È un peccato.
Kasper Holdum

1
Nel caso in cui qualcuno si imbattesse in questo come ho fatto io, Frisby non sembra essere ancora morto, come notato sopra. Il git ha aggiornamenti recenti. github.com/vlucas/frisby
S.Huston

21

Ho collaborato con uno dei miei colleghi per avviare il framework PyRestTest per questo motivo: https://github.com/svanoort/pyresttest

Sebbene tu possa lavorare con i test in Python, il normale formato del test è in YAML.

Suite di test di esempio per un'app REST di base: verifica che le API rispondano correttamente, controllando i codici di stato HTTP, sebbene tu possa fare in modo che esamini anche i corpi di risposta:

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

Con l'autenticazione, aggiungi di seguito a ciascun test a cui fa riferimento github.com/svanoort/pyresttest/blob/master/quickstart.md con le intestazioni di seguito; - auth_username: "foobar" - auth_password: "secret" - expected_status: [200]
agfe2


2

Uno dei problemi dell'esecuzione di test automatici per le API è che molti degli strumenti richiedono che il server API sia attivo e in esecuzione prima di eseguire la suite di test. Può essere un vantaggio reale disporre di un framework di unit test in grado di eseguire ed eseguire query sulle API in un ambiente di test completamente automatizzato.

Un'opzione utile per le API implementate con Node.JS / Express consiste nell'usare mocha per i test automatici. Oltre agli unit test, è facile scrivere test funzionali contro le API, separati in diverse suite di test. È possibile avviare automaticamente il server API nell'ambiente di test locale e configurare un database di test locale. Utilizzando make, npm e un server di compilazione, è possibile creare una destinazione "make test" e una build incrementale che eseguirà l'intera suite di test ogni volta che un pezzo di codice viene inviato al repository. Per lo sviluppatore veramente esigente, genererà anche un bel rapporto di copertura del codice HTML che mostra quali parti della tua base di codice sono coperte dai test o meno. Se questo sembra interessante, ecco un post sul blog che fornisce tutti i dettagli tecnici.

Se non stai usando node, qualunque sia il framework di unit test defacto per la lingua (jUnit, cucumber / capybara, ecc.), Guarda il suo supporto per la rotazione dei server nell'ambiente di test locale e l'esecuzione delle query HTTP. Se si tratta di un progetto di grandi dimensioni, lo sforzo per ottenere test API automatizzati e l'integrazione continua funzionerà abbastanza rapidamente.

Spero possa aiutare.


2

Runscope è un servizio basato su cloud in grado di monitorare le API Web utilizzando una serie di test. I test possono essere, programmati e / o eseguiti tramite web hook parametrizzati. I test possono essere eseguiti anche dai data center di tutto il mondo per garantire che i tempi di risposta siano accettabili per la base di clienti globale.

Il livello gratuito di Runscope supporta fino a 10.000 richieste al mese.

Dichiarazione di non responsabilità: sono un sostenitore degli sviluppatori di Runscope.




0

L'automazione dei test API, fino a una volta al minuto, è un servizio disponibile tramite l' API destra . Crei i tuoi scenari di test e li esegui. Una volta che questi test hanno eseguito ciò che ti aspetti, puoi programmarli. I test possono essere "concatenati" insieme per scenari che richiedono l'autenticazione. Ad esempio, puoi avere un test che effettui una richiesta OAuth a Twitter e crei un token condiviso che può quindi essere utilizzato da qualsiasi altro test. I test possono anche avere criteri di convalida allegati per garantire i codici di stato http, o anche un'ispezione dettagliata delle risposte utilizzando javascript o la convalida dello schema. Una volta pianificati i test, è possibile ricevere avvisi non appena un determinato test non supera la convalida o si comporta al di fuori degli intervalli stabiliti per il tempo di risposta o la dimensione della risposta.


Il collegamento sembra essere interrotto.
Rao

0

Ho utilizzato le classi HTTP TestNG e Apache per creare il mio framework di test API REST, ho sviluppato questo concetto dopo aver lavorato in Selenium per due anni.

Tutto è uguale, tranne per il fatto che dovresti usare le classi HTTP Apache invece delle classi Selenium.

provalo, è davvero carino e buono, hai tutto il potere di personalizzare il tuo framework di test al massimo delle tue possibilità.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.