Architektura testów automatycznych dla wielomodułowej aplikacji webowej

Prelegent: Piotr Grzesiak
Problem
Jedna z firm, będąca wiodącym dostawcą usługi giełdy transportowej w Europie Wschodniej, poprosiła mnie o konsultacje w zakresie testów automatycznych. Firma miała w planach zamawiać części oprogramowania u różnych dostawców. Każdy z nich miał dostarczyć przetestowany moduł aplikacji webowej. Oprócz tego u samego klienta powstał dział QA, który miał się zająć weryfikacją poprawności działania wielomodułowej aplikacji jako całości. Moim zdaniem było zaprojektować rozwiązanie, które pozwalałoby na realizację automatyzacji testów z uwzględnieniem następujących wymagań:
1. Aplikacja składa się z wielu modułów, z których każdy jest pisany przez inna firmę i każdy mam mieć testy automatyczne.
2. W dowolnym momencie na jednym z dwóch środowisk testowych mogła być wgrana aplikacja z modułami w różnych wersjach.
3. Testy automatyczne stawały się razem z aplikacją własnością klienta i mogły być przekazane do utrzymania i rozwoju innej firmie.
4. Wewnętrzny dział QA klienta (System Team) miał automatyzować testy E2E, które przechodziły przez wszystkie moduły.
Warunki dodatkowe
Podczas projektowania rozwiązania automatyzacji testów oprócz charakterystyki aplikacji należało wziąć pod uwagę różny poziom umiejętności automatyzacji testerów z poszczególnych firm, miejsce przechowywania kodu (początkowo różne dla różnych firm), nacisk na ograniczenie duplikowania kodu oraz skomplikowanie procesów biznesowych w poszczególnych modułach.
Rozwiązanie
Na punkt synchronizacji pomiędzy zespołami zostało wybrane repozytorium binariów – Artifactory. Dzięki temu projekty z osobnych repozytoriów mogą używać swoich klas stron.
Szablon testów automatycznych, na którego podstawie zostały utworzone projekty testów automatycznych dla wszystkich modułów, posiadał strukturę i konfigurację, która umożliwia wysłanie wszystkich klas stron projektu do Artifactory. Następnie te strony mogą być załączone do dowolnego innego projektu jako zwykłe zależności maven’a.
Co więcej, konfiguracja pliku POM powoduje, że w dowolnym momencie możemy przełączyć się pomiędzy wersjami klas stron, z których chcemy skorzystać w automatyzacji. Odpowiada to na wymaganie mówiące o różnych wersjach poszczególnych modułów w różnych środowiskach.
Szablon testów automatycznych
Aby powyższe rozwiązanie mogło działać, w zespołach odpowiedzialnych za automatyzację testów każdego z modułów od strony technicznej musiały być spełnione warunki unikalnego nazewnictwa pakietów oraz standaryzacja struktury projektów.
Wysyłanie projektu do Artifactory
Zawarcie w POM.xml adresu Artifactory oraz mavenowego goala deploy skutkuje możliwością bardzo prostego wysłania klas stron do repozytorium binariów, za pomocą polecenia: mvn deploy.
Pobieranie klas stron innych projektów
Pobieranie klas stron innych projektów odbywa się dokładnie tak jak pobieranie dowolnej biblioteki javy, czyli poprzez wprowadzenie do pliku POM.xml odpowiedniej zależności.
Po przebudowaniu projektu mamy dostęp do wszystkich klas stron, które zostały wysłane do artifactory przez zespół odpowiedzialny za automatyzację modułu logowania.
Przykład użycia
Dobrym przykładem użycia Artifactory do współdzielenia klas stron jest zastosowanie w testach wszystkich modułów jednej strony logowania oraz strony nawigacyjnej.
Po zaciągnięciu tej zależności do projektu możemy wywołać metodę logowania z wybranymi przez nas parametrami. Podobnie w przypadku metod nawigacyjnych. Po zaimportowaniu zależności modułu Frame w odpowiedniej wersji mamy dostęp do wszystkich metod nawigacyjnych w całej aplikacji.
Podsumowanie
Jak widać z przytoczonego przykładu, dzięki zastosowaniu szablonu testów automatycznych oraz współdzielenia klas stron pomiędzy projektami inżynierowie testów odpowiedzialni za testy jednego z modułów, nie muszą się w ogóle przejmować automatyzowaniem logowania oraz nawigacji. Jest to ważne szczególnie w dwóch wymiarach:
1. Zmiany w aplikacji muszą być odzwierciedlone tylko przez jeden zespół odpowiedzialny za automatyzację testów danego modułu.
2. Inżynierowie, którzy chcą wykonać akcję w innym module aplikacji, na przykład dla logowania, nawigacji czy też przygotowania danych testowych, nie muszą znać dokładnie przepływów biznesowych w innym module ani poświęcać czasu na kodowanie i utrzymanie dodatkowych metod.
Zastosowanie powyższego rozwiązania, poskutkowało wyeliminowaniem duplikowania kodu dla podstawowych akcji jak logowanie i nawigacja, umożliwiło bezproblemowe uruchamianie i analizę testów ze wszystkich modułów przez centralny zespół System Team oraz umożliwiło temu automatyzację testów wykorzystujących metody z innych modułów.


Tagged under:

Program konferencji

TwitterFacebookLinkedInGoogle+