Automatyczne testowanie interfejsu REST Api [zamknięte]

Chciałbym napisać zautomatyzowany pakiet testowy dla REST API. Gdy wykonujemy nowe usługi, chcielibyśmy sprawdzić, czy wszystkie wcześniej utworzone usługi działają zgodnie z oczekiwaniami. Jakieś sugestie dotyczące najlepszych narzędzi do osiągnięcia tego celu? Wiem, że istnieją narzędzia takie jak Apigee, które pozwalają testować 1 usługę naraz, ale chcielibyśmy mieć sposób na przetestowanie wszystkich usług za pomocą jednego kliknięcia.

W mojej pracy ostatnio zebraliśmy kilka zestawów testów napisanych w Javie, aby przetestować niektóre zbudowane przez nas API RESTful. Nasze usługi mogą wywoływać inne interfejsy API RESTful, od których zależą. Podzieliliśmy go na dwa apartamenty.

• Pakiet 1 - testowanie każdej usługi oddzielnie
  • Mock wszelkie usługi równorzędne, od których zależy API, używając Restito . Inne alternatywy obejmują rest-driver , wiremock i betamax .
  • Testuje usługę, którą testujemy, i wszystkie makiety są uruchamiane w jednej JVM
  • Uruchamia usługę w Jetty

Zdecydowanie poleciłbym to zrobić. U nas zadziałało naprawdę dobrze. Główne zalety to:

• Usługi równorzędne są wyszydzane, więc nie musisz wykonywać żadnych skomplikowanych konfiguracji danych. Przed każdym testem po prostu użyj restito, aby zdefiniować, jak mają się zachowywać usługi równorzędne, tak jak w przypadku klas w testach jednostkowych z Mockito.
• Możesz zapytać wyśmiewane usługi równorzędne, czy zostały wywołane. Nie możesz wykonać tych potwierdzeń tak łatwo w przypadku prawdziwych usług równorzędnych.
• Pakiet jest bardzo szybki, ponieważ fałszywe usługi obsługują gotowe odpowiedzi w pamięci. Dzięki temu możemy uzyskać dobre ubezpieczenie bez konieczności starania się o uruchomienie pakietu.
• Pakiet jest niezawodny i powtarzalny, ponieważ jest izolowany we własnej JVM, więc nie musisz się martwić, że inne pakiety / ludzie będą mieszać się we wspólnym środowisku w tym samym czasie, gdy pakiet działa i powoduje niepowodzenie testów.

• Apartament 2 - od końca do końca
  • Pakiet działa w pełnym środowisku wdrożonym na kilku komputerach
  • API wdrożone na Tomcat w środowisku
  • Usługi równorzędne są rzeczywistymi, pełnymi wdrożeniami „na żywo”

Ten pakiet wymaga od nas skonfigurowania danych w usługach równorzędnych, co oznacza, że ​​napisanie testów zajmuje zwykle więcej czasu. W miarę możliwości używamy klientów REST do konfigurowania danych w usługach równorzędnych.

Testy w tym pakiecie zwykle trwają dłużej, więc większość naszego pokrycia umieszczamy w pakiecie 1. To powiedziawszy, ten pakiet ma nadal wyraźną wartość, ponieważ nasze makiety w pakiecie 1 mogą nie zachowywać się tak, jak prawdziwe usługi.

Frisby to platforma do testowania REST API oparta na node.js i Jasmine, która sprawia, że ​​testowanie punktów końcowych API jest łatwe, szybkie i przyjemne. http://frisbyjs.com

Przykład:

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

Współpracowałem z jednym z moich współpracowników, aby uruchomić framework PyRestTest z tego powodu: https://github.com/svanoort/pyresttest

Chociaż możesz pracować z testami w Pythonie, normalny format testu to YAML.

Przykładowy zestaw testów dla podstawowej aplikacji REST - weryfikuje, czy interfejsy API odpowiadają poprawnie, sprawdzając kody stanu HTTP, ale można również sprawić, by badał treści odpowiedzi:

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

Użyłem interfejsu SOAP do testów funkcjonalnych i zautomatyzowanych. SOAP UI umożliwia uruchamianie testów jednym kliknięciem przycisku. Istnieje również strona testowa sterowników sprężyn stworzona przez Teda Younga. W tym artykule stworzyłem testy jednostkowe Rest w naszej aplikacji.

Jednym z problemów związanych z wykonywaniem testów automatycznych dla interfejsów API jest to, że wiele narzędzi wymaga skonfigurowania i uruchomienia serwera API przed uruchomieniem zestawu testów. Prawdziwą zaletą może być posiadanie struktury testów jednostkowych, która jest w stanie uruchamiać i wysyłać zapytania do API w całkowicie zautomatyzowanym środowisku testowym.

Opcją, która jest dobra dla interfejsów API zaimplementowanych w Node.JS / Express, jest użycie mokki do automatycznego testowania. Oprócz testów jednostkowych można łatwo napisać testy funkcjonalne względem interfejsów API, podzielone na różne zestawy testów. Możesz uruchomić serwer API automatycznie w lokalnym środowisku testowym i skonfigurować lokalną testową bazę danych. Używając make, npm i serwera kompilacji, możesz utworzyć cel „make test” oraz kompilację przyrostową, która będzie uruchamiać cały zestaw testów za każdym razem, gdy fragment kodu zostanie przesłany do repozytorium. Dla naprawdę wybrednego programisty wygeneruje nawet ładny raport o pokryciu kodu HTML, pokazujący, które części bazy kodu są objęte testami, a które nie. Jeśli brzmi to interesująco, oto wpis na blogu zawierający wszystkie szczegóły techniczne.

Jeśli nie używasz węzła, to niezależnie od tego, jaki jest framework do testów jednostkowych defacto dla tego języka (jUnit, cucumber / capybara, itp.) - spójrz na jego obsługę uruchamiania serwerów w lokalnym środowisku testowym i uruchamiania zapytań HTTP. Jeśli jest to duży projekt, wysiłek związany z automatycznym testowaniem API i ciągłą integracją opłaci się dość szybko.

Mam nadzieję, że to pomoże.

Runscope to usługa oparta na chmurze, która może monitorować interfejsy API sieci Web za pomocą zestawu testów. Testy można zaplanować i / lub uruchomić za pomocą sparametryzowanych podpięć sieci Web. Testy można również przeprowadzać w centrach danych na całym świecie, aby zapewnić akceptowalny czas reakcji dla globalnej bazy klientów.

Bezpłatna warstwa Runscope obsługuje do 10 000 żądań miesięcznie.

Zastrzeżenie: Jestem zwolennikiem programisty Runscope.

Wdrożyłem wiele przypadków automatyzacji opartych na REST Assured, jave DSL do testowania restful service. https://code.google.com/p/rest-assured/

Składnia jest prosta, obsługuje json i xml. https://code.google.com/p/rest-assured/wiki/Usage

Wcześniej próbowałem SOAPUI i miałem problemy z darmową wersją. Poza tym skrzynki są w plikach xml, które trudno jest rozszerzyć i ponownie wykorzystać, po prostu mi się nie podoba

Możesz także skorzystać z biblioteki Rest Assured. Demo z przykładowym skryptem można znaleźć pod adresem http://artoftesting.com/automationTesting/restAPIAutomationGetRequest.html

Automatyzacja testów API, nawet raz na minutę, jest usługą dostępną przez RightAPI . Tworzysz scenariusze testowe i wykonujesz je. Gdy testy wykonają to, czego od nich oczekujesz, możesz je zaplanować. Testy można łączyć ze sobą w scenariuszach wymagających uwierzytelniania. Na przykład możesz mieć test, który wysyła żądanie OAuth do Twittera i tworzy udostępniony token, który może być następnie użyty w dowolnym innym teście. Testy mogą również mieć dołączone kryteria walidacji, aby zapewnić kody statusu http, a nawet szczegółową kontrolę odpowiedzi za pomocą javascript lub walidacji schematu. Po zaplanowaniu testów możesz ustawić alerty powiadamiające Cię, gdy tylko dany test nie przejdzie walidacji lub zachowuje się poza ustalonymi zakresami czasu odpowiedzi lub rozmiaru odpowiedzi.

Użyłem klas TestNG i Apache HTTP do zbudowania własnego szkieletu testowego REST API, koncepcję tę opracowałem po dwóch latach pracy w Selenium.

Wszystko jest takie samo, z wyjątkiem tego, że powinieneś używać klas Apache HTTP zamiast klas Selenium.

spróbuj, to naprawdę urocze i dobre, masz całą moc, aby dostosować strukturę testową do swoich najpełniejszych możliwości.