Podnieś jakość oprogramowania & oszczędzaj czas dzięki testowaniu infrastruktury

Infrastruktura to termin, którym opisujemy cały sprzęt, usługi w chmurze, sieci, oprogramowanie pomocnicze oraz testowaną aplikację wymagane do tworzenia, testowania, wdrażania i obsługi naszych systemów.

Nie ma jednak sensu ograniczać naszej definicji wyłącznie do technologii. Centra danych, powierzchnie biurowe, biurka, komputery stacjonarne, laptopy, tablety i telefony komórkowe z zainstalowanymi własnymi stosami oprogramowania są częścią ekosystemu wymaganego do tworzenia, testowania i wdrażania systemów.

Jeśli uwzględnimy narzędzia dla deweloperów, narzędzia i procedury DevOps, narzędzia testowe, a także wymagane procesy biznesowe i wiedzę specjalistyczną, otrzymamy jeszcze więcej elementów.

Nawet najbardziej prozaiczne rzeczy — kody dostępu lub karty inteligentne używane do uzyskania dostępu do budynków — mogą stać się kluczowe, jeśli nie zostaną zapewnione.

Infrastruktura, we wszystkich swoich odmianach, istnieje po to, aby wspierać tworzenie, testowanie, wdrażanie i eksploatację systemów. Jest albo kluczowa dla testowania, albo wymaga testowania.

W następnym artykule przyjrzymy się narzędziom do tworzenia, testowania i współpracy. W tym artykule omówimy to, co większość osób uznaje za środowiska testowe, oraz krótko przyjrzymy się temu, co często określa się mianem testowania infrastruktury. Omówię:

• Środowiska testowe
• Środowiska programistyczne
• Środowiska testów na poziomie systemu
• Środowiska danych
• Testowanie infrastruktury

Zaczynajmy.

Środowiska testowe

Każde testowanie opiera się na niejawnym, kluczowym i upraszczającym założeniu: nasze testy będą uruchamiane w znanym środowisku.

Czym jest środowisko?

Wszystkie systemy muszą być testowane w określonym kontekście. Aby test miał znaczenie, system musi zostać zainstalowany, skonfigurowany, wdrożony lub zbudowany w realistycznym środowisku, które symuluje rzeczywisty świat, w którym będzie używany. 

Możemy na przykład korzystać ze scenariuszy testowych, które sprawdzają możliwości systemów pod względem funkcjonalności, wydajności lub bezpieczeństwa, ale są to właściwości testów, a nie środowiska.

Realistyczne środowisko odtwarzałoby wszystkie środowiska biznesowe, techniczne i organizacyjne. Znaczna część tego środowiska obejmuje dane używane do sterowania procesami biznesowymi, konfigurowania systemu i dostarczania danych referencyjnych.

Jednak idealnie realistyczne środowiska są zwykle niepraktyczne lub zbyt kosztowne (nawet testerzy systemów o krytycznym znaczeniu, takich jak samoloty, reaktory jądrowe czy skanery mózgu, muszą w pewnym momencie pójść na kompromis). Niemal wszystkie testy odbywają się w środowiskach, które symulują rzeczywisty świat przy akceptowalnym poziomie kompromisów.

Samochody są testowane na hamowniach, w tunelach aerodynamicznych, na stanowiskach wibracyjnych i prywatnych torach testowych, zanim zostaną przetestowane na drogach publicznych. Systemy komputerowe są testowane w laboratoriach oprogramowania przez programistów i testerów oprogramowania, zanim użytkownicy końcowi zostaną zaangażowani do ich wypróbowania w środowisku zbliżonym do produkcyjnego.

Aby mieć pewność, że środowiska testowe spełniają standardy branżowe, rozważ wdrożenie jednej z tych najwyżej ocenianych platform do zarządzania testami.

Testuj w realistycznych środowiskach

Środowiska symulowane są zawodne, podobnie jak nasze wymagania i modele testów, ale musimy się z tym pogodzić.

Musimy planować testy, które mają znaczenie w dostępnych nam środowiskach, a wyniki testów oznaczają to, co według naszej interpretacji oznaczają.

Wiarygodność wyników testów zależy od środowiska, w którym są one uruchamiane. Jeśli test zostanie uruchomiony w nieprawidłowo skonfigurowanym środowisku:

• Niepomyślne przejście testu może sugerować, że system jest wadliwy, podczas gdy w rzeczywistości działa poprawnie.
• Pomyślne przejście testu może sugerować, że system działa poprawnie, podczas gdy w rzeczywistości jest wadliwy.

Oczywiście obie sytuacje są wysoce niepożądane.

Konfigurowanie i dostarczanie środowisk na czas

Nawet wraz z pojawieniem się infrastruktury chmurowej środowiska testowe mogą być trudne i kosztowne w konfiguracji oraz utrzymaniu.

Gdy zespoły wsparcia pracują nad nowym środowiskiem produkcyjnym, testerzy żądają środowisk testowych (a być może kilku z nich). Na późniejszych etapach testowania zespoły wsparcia często muszą sprostać konkurencyjnym wymaganiom.

Środowiska programistyczne lub dowolne późniejsze działania testowe mogą zostać dostarczone z opóźnieniem albo wcale, mogą też nie być skonfigurowane lub kontrolowane zgodnie z wymaganiami. Nieuchronnie opóźni to testowanie i/lub podważy zaufanie do wszelkich wyników testów.

Kluczowym zadaniem jest jak najszybsze określenie potrzeby utworzenia środowiska przeznaczonego do testowania oraz wymagań wobec niego, w tym mechanizmu zarządzania zmianami w tym środowisku—tak szybko, jak to możliwe.

Infrastruktura jako kod to najnowszy etap rozwoju sposobu konstruowania środowisk, w którym narzędzia postępują zgodnie z procedurami i wykorzystują kod deklaratywny do definiowania konfiguracji środowiska. 

Chociaż podstawowe platformy systemów operacyjnych (serwery) można łatwo tworzyć w chmurze lub jako maszyny wirtualne we własnym środowisku, w pełni określone serwery specjalnego przeznaczenia, zawierające całe wymagane oprogramowanie, dane, konfiguracje i interfejsy, wymagają większego nakładu pracy.

Podczas konfigurowania infrastruktury testowej kluczowe jest zintegrowanie niezawodnego oprogramowania do zarządzania bazami danych w celu zapewnienia optymalnej wydajności

Jednak po skonfigurowaniu zapewniają one bardzo wydajny sposób tworzenia środowisk. Kod infrastruktury można kontrolować za pomocą systemu kontroli wersji tak samo jak kod dowolnej aplikacji, a także zarządzać nim poprzez proces zarządzania zmianami.

Jedną z głównych zasad ciągłego dostarczania jest jak najszybsze przekazanie przez potok dostarczania pewnego oprogramowania—nawet jeśli nie jest ono użyteczne—aby dowieść, że procesy działają. 

Oczywiście wymaga to odpowiednich środowisk do kompilacji, narzędzi ciągłej integracji, testowania na poziomie systemu i wdrażania. Celem jest wdrażanie środowisk testowych i produkcyjnych bez ograniczeń. Po utworzeniu definicji środowisk i procesów wdrażania generowanie środowisk staje się zautomatyzowanym i rutynowym zadaniem.

W każdych okolicznościach definicje tych środowisk są jednym z pierwszych rezultatów projektu.

Środowiska programistyczne

Testowanie przez programistów koncentruje się na tworzeniu komponentów oprogramowania, które dostarczają funkcje wewnątrz aplikacji lub na poziomie użytkownika albo warstwy prezentacji. 

Testy są zazwyczaj sterowane wiedzą o wewnętrznej strukturze kodu i mogą nie wykorzystywać realistycznych danych ani ich nie wymagać. Testy komponentów lub usług niskiego poziomu są zwykle uruchamiane za pośrednictwem API przy użyciu niestandardowych lub zastrzeżonych sterowników albo narzędzi.

Zakres narzędzi programistycznych, platform i tak zwanych zintegrowanych środowisk programistycznych (IDE) jest ogromny. W tym artykule możemy omówić jedynie niektóre z najważniejszych wymagań i funkcji środowisk związanych z testowaniem.

Aby wspierać programowanie i testowanie objęte zakresem prac programistów, środowiska muszą obsługiwać następujące działania. To tylko wybór—w Twojej sytuacji mogą występować dodatkowe działania lub ich odmiany:

• Środowisko „piaskownicy” do eksperymentowania z nowym oprogramowaniem. Piaskownice są często używane do testowania nowych bibliotek, tworzenia jednorazowego kodu prototypowego lub ćwiczenia technik programistycznych. Wszystkie popularne języki programowania mają setki lub tysiące bibliotek oprogramowania. Piaskownic używa się do instalowania i testowania oprogramowania, które nie jest jeszcze częścią głównego nurtu prac rozwojowych, aby je ocenić i przećwiczyć jego używanie. Środowiska te mogą być traktowane jako jednorazowe.
• Lokalne środowisko programistyczne. To miejsce, w którym programiści utrzymują lokalną kopię części lub całości kodu źródłowego swojej aplikacji ze współdzielonego repozytorium kodu i mogą tworzyć kompilacje systemu do testów lokalnych. Środowisko to pozwala programistom wprowadzać zmiany w kodzie w lokalnej kopii i testować te zmiany. Niektóre testy są wykonywane doraźnie i być może nigdy nie zostaną powtórzone. Inne testy są zautomatyzowane. Zautomatyzowane testy są zwykle zachowywane przez cały czas, szczególnie jeśli stosują podejście oparte na testach.
• Współdzielone środowisko integracji (ciągłej). Gdy programiści uznają, że ich kod jest gotowy, przesyłają zmiany do współdzielonego, kontrolowanego repozytorium kodu. Środowisko CI wykonuje automatyczne kompilacje i uruchamia zautomatyzowane testy z użyciem repozytorium. W tym momencie nowy lub zmieniony kod zostaje zintegrowany i przetestowany. System CI uruchamia zautomatyzowane testy na żądanie, co godzinę lub codziennie, a cały zespół otrzymuje powiadomienia i może sprawdzić stan testów najnowszej zintegrowanej kompilacji. Błędy są szybko ujawniane i traktowane priorytetowo.

Środowisko programistyczne lub CI obsługuje testowanie przez programistów, ale inne serwery aplikacji, usług internetowych, komunikatów lub baz danych, które tworzą kompletny system, mogą być niedostępne. 

Jeśli te systemy współpracujące nie istnieją, ponieważ nie zostały jeszcze zbudowane albo należą do firmy partnerskiej, która udostępnia wyłącznie system produkcyjny bez wersji testowej, programiści muszą tworzyć zaślepki lub atrapy tych interfejsów, aby przynajmniej móc testować własny kod. 

Narzędzia do tworzenia atrap mogą być zaawansowane, ale zaślepione interfejsy zwykle nie obsługują testów wymagających zintegrowanych danych z wielu systemów.

Jeśli programiści mają dostęp do interfejsu testowego serwera bazy danych, ich dane testowe mogą być minimalne, niezintegrowane lub niespójne i nie odzwierciedlać danych produkcyjnych. 

Współdzielone przez zespół bazy danych środowiska programistycznego zwykle nie spełniają oczekiwań. Jeśli nie ma dobrych zasad zarządzania tym współdzielonym zasobem, programiści mogą ponownie wykorzystywać, uszkadzać lub usuwać dane innych osób.

Środowiska testowe na poziomie systemu

Testowanie na poziomie systemu koncentruje się na współpracy zintegrowanych komponentów i podsystemów. 

Środowiska te zapewniają platformę wspierającą cele integracji na większą skalę, walidacji funkcjonalności oraz obsługi systemu w kontekście procesów użytkownika lub procesów biznesowych. 

Środowiska mogą być również przeznaczone do obsługi niefunkcjonalnych aspektów systemu, takich jak wydajność, bezpieczeństwo lub zarządzanie usługami.

Jedną z najczęstszych pułapek podczas testowania jest sytuacja, w której tester systemu w swoim środowisku napotyka pewien rodzaj awarii, ale niezależnie od tego, jak bardzo się stara, programista lub tester nie może odtworzyć tej awarii w środowisku programistycznym.

Jest to niemal na pewno spowodowane brakiem spójności między tymi dwoma środowiskami. Różnica w działaniu może wynikać z konfiguracji, różnic w wersjach oprogramowania lub różnic w danych bazy danych.

Różnice w danych powodujące problemy to pierwsza rzecz, którą należy sprawdzić. Zwykle można je łatwo zidentyfikować i często szybko usunąć.

Gdy występuje niezgodność wersji oprogramowania lub konfiguracji, testerzy i programiści mogą tracić dużo czasu na ustalanie przyczyny różnicy w działaniu. 

Gdy pojawiają się te problemy, często oznacza to brak komunikacji między programistą a zespołem testowym. Może to również wskazywać na utratę kontroli nad konfiguracją w procesie konfigurowania środowiska programistycznego lub testowego albo w procesie wdrażania.

Infrastruktura jako kod i automatyczne udostępnianie środowisk sprawią, że problemy ze spójnością środowisk odejdą w przeszłość.

Rodzaje dedykowanych środowisk testowych

Aby obsługiwać testy systemowe, akceptacyjne i niefunkcjonalne, środowiska muszą wspierać następujące działania (w Twojej organizacji może być ich więcej):

• (Funkcjonalne) środowisko testów systemowych. W tym środowisku system jest weryfikowany pod kątem wymagań udokumentowanych dla systemu jako całości. Wymagania mogą mieć postać obszernych dokumentów tekstowych z tabelarycznie zdefiniowanymi przypadkami testowymi przeznaczonymi do testów systemowych. W projektach zwinnych takie środowisko może być niezbędne, aby umożliwić testerom badanie zintegrowanego systemu bez ograniczania ich do określonych funkcji.
• Środowisko testów kompleksowych. O ile środowisko CI umożliwia integrowanie komponentów z podsystemami, procesy biznesowe mogą wymagać dostępności innych systemów współpracujących, które nie znajdują się pod kontrolą deweloperów. Środowiska o pełnym zakresie są niezbędne do prowadzenia testów integracyjnych na dużą skalę, testów procesów biznesowych lub ogólnych testów akceptacyjnych. Zwykle dane są kopią danych produkcyjnych lub przynajmniej mają odpowiednią skalę. Gdy konieczne jest potwierdzenie poprawności integracji na dużą skalę, przepływy danych i sterowania są sprawdzane za pomocą dłuższych ścieżek użytkownika oraz niezależnych uzgodnień danych między zintegrowanymi systemami. Kluczowe znaczenie ma zarządzanie danymi w środowiskach testowych. Jeśli już korzystasz z Jira, rozważ zwiększenie możliwości zarządzania danymi za pomocą zaawansowanych narzędzi do zarządzania testami zaprojektowanych dla Jira.
• Środowisko wydajnościowe. Środowiska te muszą zapewniać miarodajną platformę do oceny wydajności systemu (lub wybranych podsystemów). Możliwe są kompromisy w architekturze, jeśli stosowana jest nadmiarowość lub klonowanie serwerów. Jednak wolumeny danych muszą odpowiadać skali produkcyjnej, nawet jeśli dane są syntetyczne. Środowisko musi oczywiście mieć skalę umożliwiającą obsługę produkcyjnych wolumenów transakcji, aby można było wiarygodnie przewidywać wydajność systemów działających na produkcji.
• Środowiska dostępności, odporności i zarządzalności (ARM). Pod pewnymi względami środowiska te są podobne do środowisk wydajnościowych, ale w zależności od celu testów różnice mogą być nieuniknione. Testy dostępności mają na celu zweryfikowanie, czy system może działać przez dłuższy czas bez awarii. Testy odporności (często nazywane testami przełączania awaryjnego) sprawdzają, czy awarie komponentów systemu nie powodują niedopuszczalnych zakłóceń w dostarczanej usłudze. Testy zarządzalności lub operacyjne mają na celu wykazanie, że procedury administracyjne, zarządzania, tworzenia kopii zapasowych i odzyskiwania systemu działają skutecznie.

Dane w środowiskach

W niektórych bardzo dużych projektach może istnieć nawet 20 lub 30 środowisk na dużą skalę, przeznaczonych do różnych aspektów testowania, szkoleń, migracji danych i próbnych przełączeń. W mniejszych projektach środowisk będzie mniej, być może tylko jedno współdzielone środowisko lub środowisko ciągłego dostarczania — a wszystkie testy mogą być realizowane automatycznie w środowiskach tworzonych jednorazowo, a następnie usuwanych.

Wszystkie środowiska potrzebują danych, ale ich skala i stopień realizmu mogą się różnić. Poniżej przedstawiono kilka typowych sposobów pozyskiwania i zarządzania danymi testowymi. Wzorce te koncentrują się na własności (lokalnej lub współdzielonej), sposobie tworzenia (ręcznym, automatycznym lub przez kopiowanie z produkcji) oraz skali:

• Lokalne, ręcznie tworzone dane na małą skalę — odpowiednie do doraźnych testów wykonywanych przez deweloperów lub testerów.
• Lokalne, automatycznie tworzone dane syntetyczne. Odpowiednie do automatycznych testów deweloperskich lub środowisk, w których można objąć testami funkcjonalność określonych modułów lub funkcji.
• Współdzielone, ręcznie tworzone dane. Wykorzystywane w środowiskach testów integracyjnych i systemowych, często tam, gdzie dane testowe ewoluowały równolegle z testami wykonywanymi ręcznie. W razie potrzeby wykonywana jest kopia zapasowa i przywracane są dane.
• Współdzielone, automatycznie tworzone dane. Wykorzystywane w środowiskach testów integracyjnych i systemowych, w których dane testowe ewoluowały równolegle z testami wykonywanymi automatycznie lub ręcznie. W razie potrzeby są generowane i/lub przywracane z kopii zapasowych.
• Współdzielone dane syntetyczne/losowe na dużą skalę. Testy wydajnościowe i ARM wymagają spójnych danych w dużej ilości. Dane te zazwyczaj nie muszą mieć znaczenia biznesowego — dane losowe sprawdzają się dobrze i są generowane w razie potrzeby albo generowane początkowo i przywracane z kopii zapasowych.
• Współdzielone dane o znaczeniu biznesowym na dużą skalę. Testy kompleksowe, akceptacyjne lub testy użytkowników zwykle wymagają danych o znaczeniu biznesowym w odpowiedniej skali. Czasami wykorzystywane są kopie lub wyciągi z danych produkcyjnych. Należy jednak uważać, aby nie naruszyć przepisów dotyczących danych, jeśli nie zostaną one zanonimizowane lub pozbawione danych umożliwiających identyfikację.
• Ponowne testowanie i testy regresji. Potrzebny będzie znany, kontrolowany zestaw danych w znanym stanie, dlatego zwykle jest on przywracany z kopii zapasowych. Dotyczy to każdego z powyższych środowisk, ponieważ testy te trzeba ponownie uruchamiać z danymi w znanym stanie, aby niezawodnie odtwarzać awarie.

Testowanie infrastruktury

Na początku tego artykułu omówiliśmy, co obejmuje infrastruktura, a od tego czasu skupialiśmy się przede wszystkim na komponentach technicznych, czyli systemach oprogramowania, zakładając, że sprzęt — fizyczny lub wirtualny — jest dostępny.

Budując systemy po raz pierwszy, zakładamy, że infrastruktura istnieje, działa prawidłowo, zapewnia odpowiednią wydajność, bezpieczeństwo i odporność itd.

Możemy przetestować wszystkie te aspekty po zintegrowaniu naszej aplikacji i bez wątpienia ujawnić niedociągnięcia w infrastrukturze na stosunkowo późnym etapie naszych projektów. Jednak wykrycie problemów z infrastrukturą tak późno w projekcie jest zazwyczaj niezwykle uciążliwe.

• Zmiany mające na celu usunięcie awarii infrastruktury mogą wymagać znacznego przeprojektowania i zmian w naszej aplikacji.
• Wyniki testów naszej aplikacji lub całego systemu będą wymagały ponownego uzyskania.
• Jeśli zawiodą komponenty innych firm, takie jak bazy danych, usługi internetowe, sieciowe lub komunikacyjne, jesteśmy zdani na dostawców (lub społeczność otwartego oprogramowania), którzy je wspierają.

Aby mieć pewność, że nasze zaufanie do komponentów infrastruktury jest uzasadnione, możemy oprzeć się na naszym doświadczeniu (lub doświadczeniu innych) z ich wcześniejszego użytkowania. Możemy też ocenić — poprzez testowanie — ich niezawodność, zanim zobowiążemy się do wykorzystania ich w projektowaniu i budowie naszego systemu.

W zależności od badanej infrastruktury używane przez nas środowisko może być różne — od pojedynczego serwera po niemal kompletną platformę infrastrukturalną. 

Chociaż niektóre testy będą wykonywane ręcznie, w większości przypadków użyjemy narzędzi, sterowników lub robotów do symulowania obciążenia transakcjami, które generowałaby nasza aplikacja. Konieczne będzie zamockowanie lub zastąpienie atrapami następujących interfejsów:

• Interfejsy, które obecnie nie są dostępne
• Interfejsy komponentów, którym ufamy i które łatwo symulować
• Interfejsy spoza zakresu, które nie wpływają na testowaną infrastrukturę.

Infrastruktura, co oczywiste, zazwyczaj nie działa za pośrednictwem interfejsu użytkownika ani interfejsu graficznego.

Integracja naszej aplikacji z infrastrukturą będzie w większości przebiegać w formie komunikatów lub zdalnych wywołań usług. Często symulowany ruch wymaga wywołań API skierowanych do serwerów internetowych lub aplikacyjnych, serwerów komunikatów lub baz danych albo usług dostarczanych za pośrednictwem chmury lub zdalnych lokalizacji.

Wydajność i cele ARM mogą być znane — w takim przypadku można przeprowadzić testy, aby upewnić się, że cele te zostały osiągnięte.

Infrastruktura jest jednak często współdzielona z aplikacjami innymi niż nasza, dlatego znajomość jej maksymalnej przepustowości pomaga ocenić, jaka część przepustowości pozostanie po wdrożeniu naszej aplikacji.

W tym przypadku testowanie infrastruktury służy ograniczeniu ryzyka dotyczącego naszych aplikacji oraz być może innych aplikacji, które w przyszłości będą na niej oparte. 

Zapisz się do biuletynu The QA Lead, aby otrzymywać powiadomienia o publikacji kolejnych części serii. Te wpisy są fragmentami kursu Paula Przywództwo w testowaniu, który gorąco polecamy, aby dokładniej zapoznać się z tym i innymi tematami. Jeśli się zapiszesz, użyj naszego ekskluzywnego kodu kuponu QALEADOFFER, aby uzyskać zniżkę w wysokości $60 od pełnej ceny kursu!

Polecana lektura: 10 NAJLEPSZYCH NARZĘDZI OPARTYCH NA OTWARTYM OPROGRAMOWANIU DO ZARZĄDZANIA TESTAMI