Ładowanie danych testowych w projektach z automatyzacją testów

16 Marzec 2017
0 Komentarze

Każdy, kto przymierza się do zautomatyzowania testów w swoim projekcie musi w pierwszej kolejności odpowiedzieć sobie na pytanie: Jak podawać dane testowe do systemu/aplikacji, którą będzie testował?  Dane te będą wykorzystywane w testach automatycznych, a sposób ich zadawania w dużej mierze zdefiniuje, co i jak będzie można zautomatyzować.


Oto 5 najpopularniejszych sposobów ładowania danych testowych:  

  1. Dane dodawane bezpośrednio do bazy przed wykonaniem testu.  Z reguły w trakcie ładowania aplikacji na serwer (deployment), po załadowaniu lub bezpośrednio przed wykonaniem testów.

Takie rozwiązanie jest dobre kiedy:

  • struktura danych w naszej aplikacji jest mało skomplikowana,
  • chcemy szybko załadować dużo danych naraz,
  • nasz system wymaga dużej liczby danych historycznych, których uzyskanie w normalny sposób jest niemożliwe np. na skutek walidacji.

Minusy:

  • konieczność utrzymywania dużych plików ze skryptami SQL-wymi lub innych dużych plików z danymi,
  • wymagana jest bardzo dobra znajomość struktury danych w bazie danych,
  • zdefiniowana liczba danych, których nie możemy zmieniać w trakcie wykonywania testu, bez modyfikacji w bazie,
  • konieczność utrzymywania mechanizmu lub klienta do „wrzucania” danych do bazy.

 

2. Dane dodawane przez sam test automatyczny – w skutek/w trakcie wykonywania testu.  Jest to najprostsze rozwiązanie i same w sobie sprawdza się świetnie w bardzo małej skali automatyzacji.

Plusy:

  • mały poziom skomplikowania,
  • dane dodawane są w sposób w jaki robi to użytkownik,
  • możliwość mutacji danych w dowolny sposób.

Minusy:

  • brak możliwości zadawania danych historycznych – jeśli system posiada odpowiednią walidację,
  • wydłużony okres wykonywania testów (bardzo długie testy),
  • blokowanie testów funkcjonalnych na skutek drobnych błędów np. w GUI lub API. Test się nie wykonuje bo jakiś mały defekt nie pozwala dodać danych, a dana   funkcjonalność, którą chcemy przetestować działa poprawnie.

 

 3. Dane dostępne wskutek dodanych ich przez developerów  (powstają wskutek wykonania testów jednostkowych lub „hard-codowania” ich, różnego rodzaju zaślepki). Jest to dość specyficzny przypadek, niestety często spotykany, kiedy to zespół nie przemyślał w jaki sposób będą testować system, bądź daną funkcjonalność. Na dodatek jest to jedyny szybki sposób, aby przekazać funkcjonalność do testów.

Plusy:

  • możliwość szybkiego „załatania” miejsc gdzie brakuję nam specyficznych danych

Minusy:

  • brak kontroli nad danymi testowymi przez testerów,
  • brak możliwości modyfikowania danych w trakcie wykonywania testu,
  • ograniczona ilość danych.

 

4. Korzystanie z danych produkcyjnych klienta (stała lub zmienna baza danych). Takie rozwiązanie spotyka się w systemach, które ze względu na duży poziom skomplikowania lub np. przejęcia ich przez firmę A po firmie B nie przejmują zbioru danych testowych. W takiej sytuacji koszt utworzenia nowego zbioru jest znacznie większy, niż skorzystanie z danych produkcyjnych. Aplikacja wymusza takie, a nie inne podejście.

Plusy:

  • praca na rzeczywistych danych produkcyjnych,
  • możliwość pokrycia bardzo specyficznych przypadków testowych.

Minusy:

  • całkowity brak przewidywalności danych,
  • problem braku danych dla niektórych przypadków testowych,
  • brak możliwości edytowania danych.

 

5. Dane dodawane przez web-serwisy. Dane te są dodane przez klienta dodanego do testów automatycznych.

Plusy:

  • całkowita kontrola na danymi,
  • możliwość zadawania dowolnej ilości danych,
  • testowanie systemu (backendu) przez dodawanie danych na żywych końcówkach systemu (endpointach).
  • duża szybkość działania, atomowość danych per test.

Minusy:

  • brak możliwości dodawania danych historycznych jeśli API na to nie pozwala,
  • wymagana znajomości API „backendu” oraz technologi web-serwisów.

 

Wiemy już, zatem jakie są najpopularniejsze sposoby zadawania danych. Teraz musimy zastanowić się nad wybraniem najlepszego sposobu dla naszych testów.


Jak wybrać właściwy sposób?

Wybór właściwego sposobu zależy od wielu czynników takich jak architektura rozwiązania, jego przeznaczenie, sposób użycia, wielkość, walidacja i chociażby to, czy możemy dodawać dane historyczne. Musimy też pamiętać o skali naszej automatyzacji. Im skala naszej automatyzacji w projekcie będzie większa, tym nasze zdolności „ładowania” danych muszą pozwalać na więcej.

 

Dodatkowo musimy pamiętać, że sposób, w jaki będziemy zadawać dane, zdefiniuje nam czy nasze testy automatyczne będą poprawne i powtarzalne. Aby te dwie cechy były spełnione nasze testy muszą mieć następujące zasady:

  1. Testy muszą być atomowe,
  2. Testy muszą po sobie sprzątać,
  3. Testy nie mogą od siebie zależeć,
  4. Każdy test powinien być powtarzalny,
  5. Test powinien być możliwy do wykonania wielokrotnie w trakcie życia aplikacji

 

Już na pierwszy rzut okna widać, że nie wszystkie sposoby zadawania danych będą spełniać nasze 5  punktów. Jakich problemów możemy spodziewać się i co na pewno nie będzie spełnione?  

Możesz się tego dowiedzieć już 23 kwietnia o godz. 19.00 podczas bezpłatnego webinara  pt. „Tworzenie danych testowych dla testów automatycznych, przy użyciu webserwisów – na przykładzie użycia Selenium i RestAssured”. 

Mateusz Ciołek
Autor artykułu oraz prowadzący webinar: Mateusz Ciołek Inżynier testów z ponad 5 letnim doświadczeniem w branży. Na co dzień pracujący jako lider zespołu testerów automatycznych w jednej z wrocławskich firm. Pasjonat automatyzacji testów i dobrych praktyk w automatyzacji, który stara opierać się o wzorce programowania i Clean Code.

Dodaj komentarz

avatar
  Subscribe  
Powiadom o