Automatyczne testowanie interfejsu REST Api [zamknięte]

84

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.

Prasad
źródło
2
Możesz spróbować vREST . Posiada zarówno testy jednostkowe, jak i makiety.
Jangid
1
JMeter to najlepsze narzędzie do testowania REST API - dodanie tego komentarza dla osób, które szukają szczegółowych kroków do przetestowania REST API przy użyciu JMeter. testautomationguru.com/how-to-test-rest-api-using-jmeter
vins
Nic nie przebije FRISBY - Po prostu idealne i najpotężniejsze narzędzie do testowania REST API
Piyush Chordia Kwietnia
2
JMeter to przesada, nie wspominając o okropnym interfejsie użytkownika, służącym tylko do podstawowego testowania funkcjonalnego interfejsu REST. Służy do testowania wydajności / obciążenia.
Kevin M
2
JMeter koncentruje się bardziej na testowaniu obciążenia, może powinieneś sprawdzić 12 świetnych narzędzi do testowania usług internetowych, aby znaleźć najlepszą opcję. Niektóre narzędzia z tej listy, na przykład SOAPUI lub HttpMaster , mają całkiem przyzwoitą obsługę automatyzacji dla punktów końcowych REST API.
Joxi,

Odpowiedzi:

36

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.


theon
źródło
25

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();
chx007
źródło
Głosowałem na ten artykuł, użyłem go w mojej codziennej pracy, a teraz wszystkie frisbies są miotane. O tym samym podzieliłem się na moim blogu: cubicrace.com/2016/04/frisby-rest-api-automation-framework.html
Piyush Chordia Kwietnia
2
Frisby nie żyje github.com/vlucas/frisby/issues/347
Ernst Ernst
Frisby jest łatwy do rozpoczęcia i wystarczająco wydajny, aby przetestować nawet zaawansowane przepływy API. Niestety, wynik raportu pozostawia wiele do życzenia. Komunikaty o błędach, gdy interfejs API zawodzi, są prawie bezużyteczne. Co jest dziwne, biorąc pod uwagę, że wyniki po ręcznym uruchomieniu testów są całkiem dobre. Szkoda.
Kasper Holdum,
1
Na wypadek, gdyby ktoś potknął się o to tak, jak ja, frisby nie wydaje się jeszcze martwy, jak wspomniano powyżej. Git ma najnowsze aktualizacje. github.com/vlucas/frisby
S.Huston
21

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}
BobMcGee
źródło
Z uwierzytelnianiem dodajesz poniżej do każdego testu wymienionego na github.com/svanoort/pyresttest/blob/master/quickstart.md z poniższymi nagłówkami; - auth_username: "foobar" - auth_password: "secret" - spodziewany_status: [200]
agfe2
2

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.

Darren
źródło
2

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.

Darrel Miller
źródło
0

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.

zrozumiałem
źródło
Wydaje się, że link jest uszkodzony.
Rao
0

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.

Karthic.K
źródło