Jak uruchamiać testy dymne API w potoku ciągłego wdrażania

Każdego roku coraz więcej firm programistycznych przechodzi na architekturę mikrousług wykorzystującą interfejsy programowania aplikacji (APIs), ponieważ interfejsy API ułatwiają różnym zespołom pracującym nad projektem dostęp do wzajemnych zasobów. Interfejsy API umożliwiają również firmom programistycznym lub osobom prywatnym pobieranie od siebie nawzajem danych: na przykład Twitter ma interfejs API, z którego korzysta wiele małych firm w celu pobierania tweetów związanych z ich działalnością i wyświetlania ich na stronie internetowej firmy.

Inną ważną zaletą interfejsów API jest to, że są mniejsze niż aplikacja monolityczna, co oznacza, że można je często wdrażać. W firmie, w której pracuję, każdy zespół ma kilka interfejsów API, a my wdrażamy je w ośmiu różnych środowiskach. Gdybyśmy polegali wyłącznie na testach manualnych w celu sprawdzenia, czy interfejsy API zostały poprawnie wdrożone, musielibyśmy uruchamiać osiem zestawów testów dla każdego wydania interfejsu API. A gdybyśmy wdrażali więcej niż jeden interfejs API naraz, co często robimy, ponieważ nasze interfejsy API współpracują ze sobą, moglibyśmy uruchamiać setki testów. Jeśli zaś wdrażamy je co dwa tygodnie, testy te składałyby się na ogromną ilość żmudnego, powtarzalnego testowania! 

Rozwiązaliśmy ten problem, konfigurując automatyczne testy dymne interfejsów API, które uruchamiają się przy każdym wdrożeniu do każdego środowiska. W tym artykule opiszę, jak zdecydowaliśmy, co testować, oraz jak skonfigurowaliśmy nasze testy dymne. Do skonfigurowania automatycznych testów dymnych użyliśmy narzędzi Postman, Newman, Powershell i Octopus, dlatego opiszę, co zrobiliśmy przy ich użyciu. Strategie te można jednak zastosować w dowolnym potoku ciągłego wdrażania (CD).

Krok pierwszy: zdecyduj, co testować

Głównym celem testów dymnych jest wykonanie kilku prostych testów wysokiego poziomu, aby upewnić się, że wdrożenie zakończyło się powodzeniem. Nie jest to miejsce na testowanie każdej pojedynczej czynności, którą może wykonać interfejs API. Wybierając elementy do naszych testów dymnych, wzięliśmy pod uwagę następujące kwestie:

• Skonfigurowaliśmy jeden test „ścieżki sukcesu” dla każdego punktu końcowego — czyli jeden test, którego wynik powinien być pomyślny. Na przykład oczekiwano, że żądanie GET dotyczące zasobu o określonym identyfikatorze zwróci ten zasób. Warto przetestować każdy punkt końcowy raz, aby sprawdzić, czy działa zgodnie z oczekiwaniami.

• Jeśli istniały istotne różnice w sposobie korzystania z określonego punktu końcowego, dodawaliśmy jeden lub więcej testów sprawdzających te różnice. Na przykład mamy interfejs API do pobierania plików, w którym plik można pobrać na dwa różne sposoby. Punkt końcowy wygląda tak samo, ale treści żądań są różne. Dlatego dodaliśmy po jednym teście dla każdej metody.

• W przypadku punktów końcowych wymagających określonego poziomu bezpieczeństwa dodaliśmy test sprawdzający, czy żądanie bez odpowiedniego uwierzytelnienia NIE zwróci informacji, lecz zamiast tego zwróci błąd poziomu 400.

• Nie dodawaliśmy żadnych innych testów negatywnych, takich jak żądanie POST z danymi wykraczającymi poza dozwolone parametry, ponieważ uznaliśmy, że nie są one konieczne do upewnienia się, że interfejs API działa. Zamiast tego uruchamialiśmy te testy jako część nocnego zestawu testów regresji.

Krok drugi: wyeksportuj testy 

Do tworzenia naszych testów interfejsów API używaliśmy narzędzia Postman, więc po utworzeniu testów wyeksportowaliśmy zarówno kolekcję testów, jak i plik środowiska testowego do plików JSON. Dla osób, które nie znają narzędzia Postman: środowisko testowe to grupa zmiennych, do których można odwoływać się w kolekcji testów. 

Krok trzeci: napisz skrypt uruchamiający testy

Postman ma narzędzie wiersza poleceń o nazwie Newman, którego można używać do uruchamiania kolekcji testów, dlatego właśnie jego użyliśmy do uruchamiania naszych testów. Utworzyliśmy skrypt Powershell, który uruchamiał polecenie Newman. 

Krok czwarty: utwórz krok wdrażania wywołujący skrypt

Gdy skrypt Powershell był gotowy, skonfigurowaliśmy krok wdrażania w każdym projekcie wdrażania interfejsu API w Octopus, który uruchamiał skrypt testowy. Jeśli skrypt zakończył się niepowodzeniem, wdrożenie również kończyło się niepowodzeniem.

Krok piąty: uporządkuj zmienne

Zmienne są często istotną kwestią podczas uruchamiania testów dymnych w różnych środowiskach. Na przykład w środowisku kontroli jakości użytkownik testowy może mieć identyfikator 340, ale w środowisku przejściowym użytkownik testowy może mieć identyfikator 620. Innym problemem związanym ze zmiennymi jest to, że czasami ze względów bezpieczeństwa możesz nie mieć dostępu do haseł ani kluczy w środowiskach produkcyjnych. Tak było w przypadku naszego zespołu, ale na szczęście Octopus ma wartości potrzebne do uruchomienia naszych testów, więc rozwiązaliśmy ten problem, każąc Octopusowi przekazywać potrzebne wartości do naszego skryptu testowego.

Do naszego testu dymnego potrzebne były trzy różne rodzaje zmiennych:

• Typ 1: Zmienne, które nie zmieniały się w poszczególnych środowiskach testowych, takie jak „firstName”: „Prunella”. Zmienne te można było umieścić bezpośrednio w środowisku Postman, więc nie trzeba było robić z nimi nic więcej. 

• Typ 2: Zmienne, które zmieniały się w poszczególnych środowiskach testowych, ale nie musiały być zabezpieczone, takie jak „userId”: 340. Zmienne te dodawaliśmy jako zmienne Octopus w następujący sposób: „smoke.userId”, a wartość zmiennej ustawialiśmy dla każdego środowiska; na przykład dla kontroli jakości ustawiono 340, dla środowiska przejściowego 620, a dla środowiska produkcyjnego 450.

• Typ 3: Zmienne, które zmieniały się dla każdego środowiska testowego i musiały być przechowywane w bezpieczny sposób, takie jak „apiKey”: „b20628a9-3c00-4dad-b38c-0a4d2d85ffab”. Zmienne typu 3 zostały już ustawione w bibliotece zmiennych Octopus. 

Następnie użyliśmy zmiennych w następujący sposób:

1. Podczas wywoływania skryptu PowerShell w Octopus przekazywaliśmy do skryptu zmienne ustawione w Octopus. 
2. W skrypcie PowerShell odbieraliśmy przekazane zmienne Octopus i przypisywaliśmy je do zmiennych PowerShell. 
3. Podczas korzystania z polecenia Newman w skrypcie PowerShell przekazywaliśmy zmienne ze skryptu do środowiska Postman.
4. Newman używał zmiennych przekazanych w skrypcie PowerShell w połączeniu ze zmiennymi w środowisku Postman, aby uruchomić kolekcję Postman.

Dzięki uruchamianiu naszych testów dymnych API w Octopus dla każdego API i w każdym środowisku możemy mieć pewność, że wszelkie poważne problemy z wdrożeniem API zostaną natychmiast wykryte. Ponadto możemy testować środowiska produkcyjne nawet wtedy, gdy nie mamy dostępu do poufnych kluczy API. Automatyczne testy dymne wdrożeń pozwalają nam zająć się innymi rodzajami testów, takimi jak ręczne testy eksploracyjne i testy bezpieczeństwa, a także tworzyć więcej automatyzacji testów na potrzeby nocnych testów regresji. 

Aby uzyskać więcej poradników, zasubskrybuj biuletyn The QA Lead.

Ucz się dalej i posłuchaj tego podcastu: JAK OPROGRAMOWANIE OPEN SOURCE UPRASZCZA INTEGRACJĘ W INŻYNIERII AUTOMATYZACJI (Z JAMESEM WALKEREM I SANJAYEM KUMAREM)