Redakcja
Automatyzacja testów związana jest nieodłącznie z obsługą danych testowych. Dane testowe możemy podzielić na wejściowe i wyjściowe. Dane wejściowe są potrzebne do wykonania danego etapu testu, dane wyjściowe są wynikiem jego wykonania i często służą za dane wejściowe do innego testu oraz do walidacji poprawności wykonania danego etapu testu. Zbiór danych wykorzystywanych podczas jednego wykonania testu nazywamy zestawem danych testowych.
Źródło danych to mechanizm służący do dostarczania danych wejściowych i odbierania oraz zapisu wyjściowych. Źródła danych możemy podzielić na statyczne i dynamiczne. Statyczne źródła danych to takie, których zawartość jest stała, a dynamiczne to takie, w których zawartość może się zmieniać w trakcie wykonywania testu. Źródła danych możemy podzielić również na wewnętrzne i zewnętrzne. Wewnętrzne źródła danych dostarczają dane bezpośrednio z wykonywanego kodu, zewnętrzne korzystają z różnego rodzaju plików znajdujących się poza kodem skryptu.
Przygotowanie danych
Zanim wykorzystamy dane w testach, musimy je przygotować. W zależności od specyfiki danych oraz zapotrzebowania dane testowe przygotowujemy w różny sposób. Jeśli potrzebujemy niewielkich ilości możemy przygotować je ręcznie. Najczęściej jednak wykorzystujemy do tego celu specjalistycznych narzędzi do generowania danych. Zdarza się, że dane testowe wyciągamy z aplikacji lub bezpośrednio z bazy danych testowanego systemu lub systemów trzecich. Popularną metodą pozyskiwania danych jest również ich generowanie poprzez skrypt wykonujący procesy bezpośrednio na aplikacji.
Izolacja danych
W prawidłowo zaprojektowanych automatach dane testowe są odizolowane od kodu skryptów. Takie podejście daje dużą elastyczność kodu, a co za tym idzie możliwość tworzenia automatów dla wielu środowisk tworząc jeden kod w obrębie jednej wersji aplikacji. Aby izolacja danych była możliwa, musimy wykorzystać zewnętrzne źródła danych wraz z odpowiednią konfiguracją umożliwiającą wybór odpowiednich danych.
Popularne źródła danych
Istnieje wiele różnych sposobów na przechowywanie danych testowych. Omówię te, z których do tej pory korzystałem. Oczywiście zakładam istnienie innych rozwiązań, które w specyficznych sytuacjach mogą być lepsze lub łatwiejsze w użyciu.
Kod
Istnieje kilka sposobów na dostarczanie danych testowych bezpośrednio z kodu, czyli bez zaangażowania źródeł zewnętrznych. Oczywiście dobre praktyki wskazują na wyodrębnienie takiego kodu do dedykowanych klas lub bibliotek. Jedną z metod jest przechowywanie gotowych danych w tablicach lub listach zdefiniowanych bezpośrednio w kodzie. Takiej metody używamy do przechowywania małej ilości danych np. w testach jednostkowych. Zaletą i jednoczenie wadą takiego rozwiązania jest konieczność edycji danych w kodzie. Podczas tworzenia skryptów jest to wygodne, ale kiedy chcemy zmienić dane bez ingerencji w skrypt, staje się to raczej utrudnieniem.
Inną metodą jest generowanie danych „w locie”, czyli w trakcie wykonywania testu. Generalnie, jeśli specyfika testu na to pozwala, chętnie z niej korzystam. Szczególnie jeśli tworzę skrypty do testów wydajnościowych. Zaletą tej metody jest bardzo szybka zmiana danych, bo zmieniamy de facto sposób ich generowania, ale wadą jest niewątpliwe sama konieczność zaimplementowania takiego mechanizmu.
Ostatnio coraz bardziej popularną metodą w automatyzacji testów funkcjonalnych staje się tworzenie dedykowanych kreatorów danych (z ang. data builder), które stanową odrębne klasy w strukturze kodu. Największą zaletą tej metody jest prostota ich tworzenia i wygoda użycia. Sposób tworzenia takich mechanizmów narzuca pewien porządek w kodzie. W przypadku skryptów, które będą długo utrzymywane z pewnością jest to duży plus.
Pliki CSV
Pliki CSV najczęściej wykorzystywane są jako statyczne źródła danych, tam gdzie potrzebny jest tyko odczyt. Dlatego też mechanizmy do obsługi tego typu plików posiadają praktycznie wszystkie znane mi narzędzia do testów wydajnościowych. Zaletą pliku CSV jest to, że bardzo łatwo odczytywać z nich dane, szczególnie, kiedy odczyt następuje sekwencyjnie wiersz po wierszu. Dużo bardziej skomplikowana, choć możliwa w takich plikach jest operacja modyfikacji lub usuwania danych. Inną wadą plików CSV jest jego ręczna edycja. Zazwyczaj potrzebujemy do tego celu odpowiednich edytorów szczególnie, kiedy w pliku występuje dużo pustych wartości.
Pliki Excel
Ten rodzaj plików wykorzystywany jest głównie w automatach do testów funkcjonalnych. Większość narzędzi posiada gotowe mechanizmy do pracy na takich plikach, ale zaimplementowanie własnych też nie stanowi dużego problemu. Ten rodzaj plików dobrze sprawdza się również jako dynamiczne źródło danych, czyli tam, gdzie potrzebny jest zarówno odczyt, jak i zapis danych. Dużą zaletą plików Excel jest wygodna edycja jego zawartości oraz możliwość filtrowania i wyszukiwania danych.
Pliki XML
Tego rodzaju źródła danych wykorzystywane są raczej rzadko, pomimo tego, że niektóre narzędzia dostarczają gotowe mechanizmy do ich obsługi. Ich kluczową cechą jest drzewiasta struktura danych. W specyficznych sytuacjach, gdy mamy zróżnicowaną strukturę danych, warto używać tego rodzaju plików. Jeśli jednak nasze dane mają strukturę tabularyczną, obsługa plików XML będzie raczej utrudnieniem. Pliki te możemy edytować w zwykłym notatniku, ale łatwo przy tej okazji popełnić błąd i naruszyć poprawną strukturę XML. Zaleca się raczej użycia do tego celu dedykowanych edytorów. Istotną cechą plików XML jest możliwość zbudowania dla nich schematu (plik XSD), który będzie pomocny zarówno przy manualnej edycji plików, jak i programowej walidacji ich struktury i zawartości. Dodatkowym atutem plików XML jest duża dostępność gotowych funkcji przekształcających ich zawartość w obiekty i na odwrót (Marshalling/Unmarshalling). Wykorzystanie takich rozwiązań pozwala pracować na plikach XML jak na gotowych obiektach bez konieczności tworzenia dodatkowych mechanizmów.
Bazy danych
Coraz częściej narzędzia do testów wyposażane są w mechanizmy pozwalające na korzystanie z bazy danych. Niestety większość funkcjonalności, jakie standardowo dostarczane są w narzędziach do testów, ograniczają się do tego, co mamy na plikach płaskich. Zaletą baz danych jest łatwość zarówno odczytu, jak i zapisu danych. Jeśli jednak potrzebujemy bardziej wysublimowanych mechanizmów, sami musimy zaprojektować strukturę tabel i wykonać szereg mechanizmów do jej obsługi. Nie jest to bardzo skomplikowane, ale z pewnością potrzebna jest podstawowa wiedza oraz czas na ich wykonanie i przetestowanie. Zaletą bazy danych jest niewątpliwie możliwość wielowątkowego dostępu do danych, chociaż przy dużych testach wydajnościowych nie unikniemy kilku małych problemów. Zdarza się, że jako źródło danych testowych wykorzystujemy aplikacyjną bazę danych. Może to być bardzo wygodne, ale musimy być przy tym ostrożni i z powodu bezpieczeństwa używać tyko odczytu. Trzeba dodać, że aplikacyjnej bazy danych w żadnym wypadku nie powinniśmy używać do testów wydajnościowych.
Databucket
Zdarzają się projekty, w których potrzebujemy większej elastyczności w zarządzaniu danymi. Do takich sytuacji zaliczamy np. potrzebę przekazywania danych pomiędzy skryptami, wielowątkowy dostęp do danych, jednoczesny dostęp do tych samych danych z wielu narzędzi lub z wielu maszyn czy też wykorzystanie danych jednorazowego użytku. Zazwyczaj w takich sytuacjach tworzymy własne mechanizmy, które dostarczają i odbierają dane w odpowiedni dla nas sposób. Wykonanie potrzebnych mechanizmów nie musi był wcale skomplikowane, ale zawsze wiąże się z dodatkowym czasem. Bez większego nakładu pracy możemy użyć gotowego rozwiązania, jakim jest Databucket. Jest do dynamiczne źródło danych oparte na bazie danych z interfejsem w postaci mikrousługi (REST JSON). Jest to na tyle elastyczne rozwiązanie, że powinno zaspokoić nawet najbardziej niestandardowe potrzeby związane z obsługą danych.
Więcej na temat Databucket znajdziesz na www.databucket.pl.
Nie ma idealnego źródła danych sprawdzającego się we wszystkich sytuacjach. To, gdzie przechowujemy dane i w jaki sposób z nich korzystamy uzależnione jest głównie od potrzeb danego testu lub narzędzia, z jakiego korzystamy. Zdarza się jednak, że korzystamy z jakiegoś źródła danych, które w danej sytuacji sprawdza się średnio, ale jesteśmy do niego przyzwyczajeni lub mamy gotowe mechanizmy do jego obsługi. Projektując automaty testujące musimy często wybierać pomiędzy prostymi, ale ograniczonymi funkcjonalnie źródłami danych a bardziej skomplikowanymi, lecz dostarczającymi więcej możliwości. Dobrze zaprojektowany framework testowy w razie potrzeby powinien umożliwić w miarę bezbolesne przepięcie się z jednego źródła danych na inne. Ważne, aby nasz wybór podejmowany był świadomie z uwzględnieniem zarówno plusów, jak i minusów danego rozwiązania.
Autor: Krzysztof Słysz
