środa, 10 września 2014

Use Selenium for easier UAT testing

Selenium w służbie UAT....
8 lat temu, gdy zaczynałem pisać aplikacje webowe oparte na GWT, ktoś z mojego zespołu wprowadził narzędzie do testowania o nazwie Selenium.
Wydawało się być super i sprawdziło się wtedy, ale pojawiły się też inne problemy związane z testowaniem z tym narzędziu jak :
 - powtarzalność
 - utrzymywalność
 - ajax
 - wytwarzanie testów.

Genaralnie idea była bardzo dobra. Każdy kto pisał frontend miał za zadanie testować swój kawałek funkcjonalności. Istniały profile w mavenie i ja odpalałem tylko testy, które mnie dotyczyły. Dodatkowo  jest to fajnie zorganizowane w mavenie bo możemy się wstrzelić w daną fazę bez większych problemów.
Było to coś na kształt kodu poniżej : 

Zaczynamy ......czyli z krótki wstęp... Trochę o testach już pisałem tutaj


Testy funkcjonalne – są to testy mające zagwarantować, iż cała praca analityków, biznesu oraz programistów nie poszła na darmo. Zazwyczaj testy takie są przeprowadzane przez testerów. Jednak rozwój w dziedzinie IT spowodował automatyzację wielu procesów czy zadań.
Dziś standardem oraz dobrą praktyką jest pisanie różnego rodzaju testów w każdej chwili wytwarzania oprogramowania.
Tak samo wygląda sprawa z testami funkcjonalnymi (znane także jako testy UAT). Tego typu testy zaliczamy do kategorii black box, ponieważ nie interesuje nas kod a tylko wynik działania jakiejś funkcjonalności.
Punktem wyjścia do tego typu testów jest przygotowanie zbioru danych wejściowych oraz wyjściowych.
Dane wejściowe są wprowadzane do systemu, a odpowiadający im dane wyjściowe są porównywane do tych które zwróci nam aplikacja.
Testy funkcjonale warto umieścić na maszynie Continuum Integration co pozwoli nam na periodyczne lub na żądanie odpalanie takich testów. Dzięki czemu uzyskamy regresję oraz możliwość sprawdzenia czy developerzy nie uszkodzili starej funkcjonalności dodając lub poprawiając nową.

Testy funkcjonalne testują nam wszystkie warstwy aplikacji od warstwy danych do warstwy prezentacji oraz ich integrację ze sobą. (nie myl z testami integracyjnymi....)
Ponadto stanowią idealną dokumentację projektu. Mając stworzone takie testy możemy łatwo zrozumieć funkcjonalność, oraz intencje autora systemy czy danej funkcjonalności. Wspomagają również procesy refaktoryzacji.

Tip : Testy i kod są najlepszą dokumentacją projektu

Za pomocą tego rodzaju testu możemy zweryfikować :
- błędy w kodzie źródłowym
- brak implementacji wymagań biznesowych
- niepoprawna implementacja wymagań

Selenium pozwala nam wykonać testy typu : UAT czy e2e(end-to-end) oraz ich automatyzację.


Selenium jest tak naprawdę typem frameworka do testowania aplikacji webowych.
Współpracuje z przeglądarkami jak : IE, Firefox,Google Chrome czy Safari.
Należy pamiętać iż nie wspiera rozwiązań typu Silverlight, Flex/Flash czy JavaFx.
Framework ten składa się z narzędzi jak :
- Selenium IDE – plugin do Firefoxa dzięki któremu użytkownik może nagrać interesujący go przypadek testowy
(działanie JS + DOM)

- Selenium WebDriver – odpala nagrany test na różnego typu przeglądarkach (proxy pomiędzy kodem testowym a dowolną przeglądarką). Dostarcza nam API do iteracji z przeglądarką oraz sterownik umożliwiający tego typu połącznie.

(wpiera również wiele języków od javy zaczynając po PHP czy Ruby)
- Selenium Standalone Server – pozwala na zdalne wywoływanie skryptów Selenium.

Upraszczając do minimum Selenium ma za zadanie udawać akcje zwyczajnego użytkownika, poprzez kliknięcia na linki, przyciski, wybierając opcje z combo czy testować obecność tekstu czy kontrolki na formularzu.
Możemy też robić screenshot'y co czasem może być przydatne.




źródło : http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=selenium_rc


Rozwiązanie  1.

1. Pierwszy krok to nagranie testu za pomocą narzędzia Selenium IDE. 
Ze strony producenta http://seleniumhq.org należy ściągną i zainstalować plugin do Firefoxa.

Po zainstalowaniu wygląda to tak :


Kliknięcie na 'czerwony przycisk' powoduje zaczęcie nagrywania scenariusza testowego. Mamy do dyspozycji także asercje, które działają identycznie jak przypadku unit testów czyli weryfikują daną wartość zgodnie z naszymi oczekiwaniami.
(Asercja – sprawdzenie czy element znajduję się na stronie)
Nagrany test możemy wyeksportować do danego języka programowania w postaci unit testu.
Taki test powinien być wywoływany w ramach testów integracyjnych na maszynach Contiuum Integration.
Możemy też testy pogrupować w logiczne części i wtedy otrzymamy odpowiednik 'suite testu' z testów jednostkowych.

Nagrany test wygląda jak poniżej :































 
Następny krok to eksport do danego języka programowania w naszym przypadku javy.































 
Zatrzymajmy się chwilę ....
 
- dostajemy narzędzie do nagrywania testów i ich odtwarzania

- współpracuje one z wieloma przeglądarkami

- mamy możliwość asercji oraz lokacji pól, treści czy id kontrolek na stronie (findElement() and findElements())

to daje duże możliwość :

- sprawdzenie czy dana klasa czy id w css istnieje

- wsparcie dla aplikacji używających ajax

- ładowanie strony bądź jej kawałka (waitForPageToLoad, waitForFrameToLoad)

- pop up (waitForElementPresent)

- progress bar (waitForElementPresent)

- statusy wiadomości (waitForTextPresent waitForAlertPresent)

- dostępność przycisków np. button'a (waitForElementPresent)

Możemy wskazać lub znaleźć (lokacja) element dzięki po :
   - id

   - nazwie

   - linku

   - Xpath

   - CSS

Tutaj pomocy może się okazać program typu FireBug. Dzięki któremu szybko i bezboleśnie można znaleźć interesujące nas informację na temat kontrolek czy widgetów na danej stronie.

Zalety :

   - Łatwy sposób wygenerowania testów typu UAT

Wady :

   - rozwiązanie to nadaje się jedynie do prostych przypadków. Nie obsługujemy odpowiednio transakcji po stronie bazy więc po każdym teście istnieje możliwość pojawienia się duplikacji czy ujawnienia ograniczeń na bazie.

   - nieutrzymywalność oraz powtarzalność

- często nieobliczalne w stosunku do rozwiązań ajax (callback time problem)

Rozwiązanie 2.
 
(Selenium DSL)
Rezygnujemy całkowicie z narzędzia Selenium IDE. Nie nagrywamy testów z poziomu przeglądarki.

Test piszemy tylko w javie symulując w prostej linii co ma na myśli użytkownik. 
Projektujemy generyczne rozwiązanie zawierające obsługę formularza, akcje, stawianie asercji.
Oraz składnice danych testowych i transakcyjny mechanizm wycofujące dane po każdym teście. 

Zaleta :

   - skomplikowane systemy testów

    - baza danych pozostaje spójna cały czas, transakcje po teście są wycofywane
    - utrzymywalność
    - powtarzalność

Wada:

   - wymaga dużej wiedzy na temat testowania i doświadczenia programistycznego.

   - relatywnie duży koszt wytworzenia


Wniosek :
Nie traktuj Selenium jako silver bullet. Dobre utrzymywalne i powtarzalne testy będą kosztowamy zawsze sporego przynajmniej na wstęp nakładu pracy.
Ale rozwiązania generyczne i modułowe zawszę przynoszę zyski w długofalowej perspektywie.  

Brak komentarzy:

Prześlij komentarz