2

Przetwarzanie

języka naturalnego

www.sdjournal.org Software Developer’s Journal 08/2007

Automatyzacja procesu testowania warstwy prezentacji

Nikogo już chyba nie trzeba przekonywać, że testo-wanie aplikacji przed wprowadzeniem na rynek jest niezbędne. Robią tak wszystkie szanujące się

firmy dbające o reputację i stan konta. Wymierne korzyści wynikające z wplecenia procesu testowania w proces two-rzenia aplikacji (ang. test driven development) są przed-miotem wielu opracowań i stają się udziałem coraz więk-szej ilości firm stosujących metodologię zwinnego zarzą-dzania projektami (ang. agile methodologies). Proces testo-wania jest coraz częściej nieodłącznym elementem procesu budowy aplikacji, co jest z powodzeniem realizowane po-przez narzędzia wspierające budowę aplikacji.

Testowanie aplikacji jest procesem żmudnym, podat-nym na błędy oraz wymaga częstego powtarzania; natu-ralne jest zatem dążenie do zautomatyzowania tego pro-cesu. Automatyzacja taka jest możliwa w różnym stopniu dla różnego rodzaju testów. Stosowane powszechnie testy jednostkowe pozwalają na zautomatyzowanie badania po-prawności działania pojedynczej klasy (a dokładnie działa-nia zgodnego ze stworzonym zestawem testów). Wykorzy-stywane w tym procesie biblioteki JUnit, TestNG czy NU-nit są również często używane do testowania bardziej zło-żonego kodu kompletnych komponentów uruchamianych w lub poza kontenerem. Proces tworzenia i automatyzacji takich testów jest powszechnie znany.

Najwięcej trudności sprawia testowanie graficznych in-terfejsów użytkownika. Testowanie GUI, czyli innymi sło-wy warstwy prezentacji aplikacji, polega bardzo często na jej ręcznym przeklikiwaniu przez coraz bardziej znudzo-nych testerów. Jest to zajęcie czasochłonne, żmudne, po-datne na błędy, niezbyt efektywne, a przy braku dobrej or-ganizacji pracy oraz repozytorium scenariuszy testowych praktycznie nieweryfikowalne. Trudno uważać takie roz-wiązanie za dobre – proces testowania warstwy prezenta-cji również warto zautomatyzować, choć nie jest to łatwe, a często wydaje się prawie niemożliwe.

Korzyści i problemy automatyzacji procesu testowania GUIAutomatyzacja procesu testowania graficznego interfejsu użytkownika (ang. GUI – graphical user interface) może dostarczyć wielu korzyści. Najważniejsze z nich to:

• powtarzalność testów – a więc możliwość wielokrotne-go odtwarzania identycznych sekwencji testów;

• kompletność wykonania – testy wykonują się dokład-nie, tak jak zostały zdefiniowane (bez, często stosowa-nych przy ręcznym testowaniu, uproszczeń scenariu-szy);

• skrócenie czasu testowania – z reguły wykonują się o wiele szybciej niż potrafi to zrobić tester, nie potrzebu-ją przerw i bez protestu wykonują się „po godzinach”;

• wykrywają więcej „drobnych błędów”, czyli takich, które łatwo jest przeoczyć testerowi;

• „zmuszają” do systematycznego budowania repozyto-rium testów, czyli zestawu testów rozszerzanego o no-we funkcje aplikacji oraz nowe przypadki błędnego działania;

• gwarantują zgodność funkcjonalności w kolejnej wersji aplikacji poddanej zmianom (ang. Refactoring);

• niższy koszt – automatyzacja testów jest jedną z naj-szybciej zwracających się inwestycji w firmie (i to uwzględniając wyłącznie redukcję wydatków ponoszo-nych bezpośrednio na testerów).

Podstawowym problemem pozostaje jednak sposób two-rzenia, uruchamiania oraz utrzymania testów – testy, po-dobnie jak aplikacja, wymagają utrzymania, czyli dostoso-wania do zmian wprowadzanych w aplikacji. Najbardziej znanym podejściem tworzenia zestawu testów jest nagry-wanie akcji wykonywanych przez testera, tak by mogły być one następnie powtórzone bez jego udziału. Aplika-cja testująca przechwytuje i zapamiętuje ruch myszki oraz

Dariusz GołąbDominik Radziszowski

Jest pracownikiem Europejskiego Instytutu Technologii In-formatycznych i Certyfikacji EUTECert, gdzie zajmuje się za-gadnieniami testowania aplikacji.

Kontakt z autorem: darek.golab@eutecert.euJest pracownikiem Katedry Informatyki Akademii Gór-

niczo-Hutniczej, ekspertem z zakresu technologii Java oraz inżynierii oprogramowania.

Kontakt z autorem: dr@agh.edu.pl Rysunek 1. Ogólna architektura działania oprogramowania Squish

�����������������������������������������������

���

����������������

�������������������������

�������������

��������������������

�����������

3www.sdjournal.orgSoftware Developer’s Journal 08/2007

zdarzenia generowane przez klawiaturę; tak przygotowany test może

być odtwarzany bez udziału człowieka. Atrakcyjność tego podejścia w znacznym stopniu ograniczają następujące fakty:

• test może być poprawnie odtworzony wyłącznie przy tej samej rozdzielczości ekranu, czcionek i na tym samym systemie opera-cyjnym, na którym był przygotowany (w innym przypadku klik-nięcia mogą wystąpić w miejscach przypadkowych, co sprawi, że przebieg testu będzie zdecydowanie odbiegał od zamierzonego);

• poprawienie testu jest najczęściej niemożliwe – musi on być naj-częściej nagrywany od początku;

• nie można w prosty sposób weryfikować czy zawartość wyświe-tlanych przez aplikację okienek jest zgodna z oczekiwaną.

Powyższe problemy narastają jeśli rozważy się warstwę prezentacji aplikacji opartą na WWW. Wykorzystanie aplikacji poprzez prze-glądarkę internetową jest coraz popularniejsze i już od kilku lat two-rzone są biblioteki pomagające w ich testowaniu. Najbardziej zna-ne, otwarte narzędzia dla środowiska Java to HttpUnit lub HtmlU-nit. Większość z nich działa na podobnej zasadzie: symuluje klien-ta http. Aplikacja testująca wysyła żądanie dostępu do konkretne-go adresu (zarówno metody POST jak i GET) oraz parsuje przycho-dzące od serwera odpowiedzi w poszukiwaniu wymaganych danych. Podejście takie jest wystarczające dla bardzo prostych aplikacji. Pro-blemy pojawiają się przy próbie wykorzystania w stronach języka Ja-vaScript, osadzenia kontrolki albo apletu. Równocześnie nawet po-

Rysunek 2. Uproszczona architektura działania Squish z wykorzystaniem Squish IDE

����������

����������������

��������������������

�����������

���

������������� ������������� ������

����

������

�����

Rysunek 3. Konsola Squish for Web

4

Przetwarzanie

języka naturalnego

www.sdjournal.org Software Developer’s Journal 08/2007

zytywne wykonanie wszystkich testów nie gwarantuje, że aplika-cja będzie poprawnie działać dla konkretnej kombinacji: system operacyjny/przeglądarka. W rzeczywistości bowiem przetestowana została zgodność aplikacji z konkretnym narzędziem testującym a nie z przeglądarką.

Automatyzacja testowania graficznych interfejsów aplikacji, w tym interfejsów opartych na WWW nie jest rzeczą prostą. Istnieje jednak narzędzie, które może ten proces znacznie ułatwić – jest to oprogramowanie Squish firmy Froglogic.

Koncepcja oprogramowania SquishSquish jest zaawansowanym narzędziem do automatycznego testo-wania graficznego interfejsu użytkownika. Rozwiązanie to lokuje się pomiędzy wspomnianą wcześniej aplikacją rejestrującą ruch myszki i akcje wykonywane na klawiaturze oraz narzędziem symulującym klienta http. Squish łączy zalety obu podejść. Działa ponad graficz-nym interfejsem użytkownika, lecz w sposób bardziej inteligentny od aplikacji rejestrującej ruch myszki i klawiatury. Squish nagrywa ak-cje wykonywane podczas używania/testownia aplikacji, nie rejestru-je jednak współrzędnych punktów, w których wystąpiło kliknięcie. Identyfikuje on wykorzystywane komponenty interfejsu użytkowni-ka (np. lista rozwijana, przycisk itp). Umożliwia to uruchomienie te-stu przy innych ustawieniach komputera niż podczas nagrywania, na zupełnie innej maszynie oraz uodparnia na sytuację przestawiania komponentu w ramach konkretnego widoku GUI.

W czasie testowania wykorzystywane są dwa główne elementy: badana aplikacja (AUT) oraz skrypt, który ją testuje. Podstawowa za-sada jest taka, że skrypt oraz AUT uruchamiane są zawsze na dwóch

niezależnych procesach. Dzięki temu nawet błędne działanie AUT nie pociąga za sobą problemów z poprawnym wykonywaniem skryp-tu. Inną korzyścią wynikającą z tego rozwiązania jest fakt, iż pozwa-la ono na stworzenie repozytorium testów przechowywanego w pew-nej głównej lokacji i zdalne testowanie aplikacji na innych maszy-nach. Jest to rozwiązanie szczególnie użyteczne podczas testowania GUI. Komunikację między skryptem, a AUT obsługuje serwer Squ-ish. Skrypt testujący wykonywany jest za pomocą narzędzia squish-runner, natomiast AUT do połączenia z serwerem wykorzystuje od-powiednią bibliotekę (hook library) – Rysunek 1.

Z perspektywy twórcy testów separacja taka nie musi być wi-doczna. W przypadku korzystania z graficznego środowiska Squish IDE do nagrywania i wykonywania testów komponenty używane są w uproszczony sposób, pokazany na Rysunku 2.

Squish for WebSquish for Web to edycja Squish pozwalająca na testowanie aplika-cji webowych, w tym aplikacji wykorzystujących technologię Ajax. Squish for Web umożliwia testowanie stron www zawierających kombinację (D)HTML i JavaScript, a także dynamicznych i inte-raktywnych elementów (np. Struts menu). Squish wykorzystuje różne sposoby identyfikacji elementów HTML i DOM, co pozwala na two-rzenie testów bez potrzeby modyfikacji badanej aplikacji.

Nagrywanie testuInstalacja Squish za pomocą dołączonego instalatora jest bezproble-mowa, do nagrywania testów można przystąpić zaraz po jej zakoń-czeniu. Aby nagrać pierwszy test należy utworzyć grupę testów (ang.

Rysunek 4. Nagrywanie testu z wykorzystaniem narzędzia Squish

5www.sdjournal.orgSoftware Developer’s Journal 08/2007

test suite). Robi się to przy użyciu prostego kreatora, który umożli-wia wybór języka skryptowego dla należących do grupy testów oraz miejsca, w którym zostanie ona zapisana. Odpowiedni podział te-stów ułatwia późniejsze sprawdzanie poprawności działania jedynie wybranych testów, obejmujących wybrane funkcje testowanej aplika-cji. Ustalone przez użytkownika nazwy grup i testów są automatycz-nie uzupełniane o prefiksy, odpowiednio ‘suite’ lub ‘tst’. Do grupy te-stów dodajemy testy, które są tworzone przez nagrywanie akcji użyt-kownika – Rysunek 3.

Zanim rozpocznie się nagrywanie akcji, Squish poprosi o wy-bór metody synchronizacji. Trzeba zdecydować czy czasy oczeki-wania na obiekty mają być stałe przy każdym odtwarzaniu, czy wy-korzystana ma być funkcja waitForObject, która pozwala wstrzymać odtwarzanie nagranych akcji do momentu, aż obiekt osiągnie goto-wość (pozwala to uniknąć sytuacji, w której w trakcie odtwarzania testu wykorzystywane są komponenty GUI, które nie zostały jeszcze do końca załadowane/zainicjalizowane). Wybór synchronizacji znaj-duje odzwierciedlenie w otrzymanym po nagraniu skrypcie. Najwy-godniejszym podejściem jest nagranie testów z opcją snooze, która ustawia odstępy między akcjami na konkretną wartość czasu, a na-stępnie, już w trakcie edycji skryptu, wstawienie funkcji waitForO-bject w pewnych krytycznych miejscach, w których czas ten jest nie-wystarczający, bądź zmienny. Przed rozpoczęciem nagrywania nale-ży również określić czy obiekty mają być identyfikowane po jednym czy po wielu parametrach i oczywiście podać URL, wskazujący apli-kację, która ma być testowana. Kiedy wszystkie opcje są już ustawio-ne można zatwierdzić wybór i po otwarciu okna przeglądarki rozpo-cząć „przeklikiwanie” aplikacji. Nagrywanie testu możemy w dowol-nym etapie zatrzymać lub zakończyć, umożliwia to niewielkie menu Squish, dostępne w trakcie, gdy test jest nagrywany – Rysunek 4.

W momencie kliknięcia używane obiekty są identyfikowane i dodawane do mapy obiektów, a skrypt rozszerzany jest o zarejestro-waną akcję – Rysunek 5.

Każdy obiekt w mapie obiektów ma dwie nazwy: prawdziwą – zawierającą parametry, po których został zidentyfikowany, oraz sym-boliczną, pod którą występuje w skrypcie. Dzięki temu, jeżeli któ-ryś z parametrów obiektu z pewnych przyczyn ulegnie zmianie wy-starczy zmodyfikować jeden wpis w mapie obiektów, aby przywrócić poprawność testu. Po wykonaniu wszystkich zaplanowanych czynno-ści można zakończyć nagrywanie i przyjrzeć się bliżej otrzymanemu skryptowi – Rysunek 6. Skrypt jest na tyle czytelny, że jego edycja

już po nagraniu nie powinna przysporzyć trudności.

Dodanie warunków sprawdzających poprawność.Zapisany skrypt jest teoretycznie od razu gotowy do użycia, tzn. można go uruchomić w celu testowania aplikacji bez modyfikowania go. Jeżeli skrypt nie wykona się w całości może to świadczyć o tym, że testowana aplikacja nie działa właściwie. Należy się jednak zasta-nowić czy fakt, iż podczas odtwarzania testu nie pojawił się komuni-kat o błędzie wystarczy by stwierdzić, że aplikacja działa poprawnie. Oczywiście nie. Aby wnioskować o poprawności działania nie wy-starczy wiedzieć, czy wszystkie nagrane akcje wykonały się, trzeba dodatkowo stwierdzić, że przyniosły one oczekiwany efekt, w szcze-gólności poprzez weryfikację zawartości wyświetlanych w czasie te-stu okienek. Mógłby to robić tester śledząc wykonanie testów, ale wtedy trudno byłoby nazwać takie testy automatycznymi.

Squish pozwala przeprowadzić weryfikację poprawności zawar-tości testowanych elementów GUI, dzięki mechanizmom umożliwia-jącym sprawdzanie ich stanu. Robi się to poprzez wstawianie do te-stowanego skryptu punktów weryfikacji. Możliwe jest automatyczne rozszerzenie skryptu, poprzez wskazanie elementów GUI oraz wybór takich ich właściwości, których stan ma być każdorazowo sprawdza-ny. Skrypt można również bardzo łatwo rozszerzyć ręcznie, np. wy-korzystując funkcje test.compare lub test.verify. Możemy dzięki temu zweryfikować np. czy jeśli nie zostało wypełnione obowiązkowe po-le formularza testowana aplikacja zwróciła formularz ponownie, ale z odpowiednim komunikatem oraz czy zawartość pól wypełnionych poprawnie nie została utracona. Weryfikacja będzie przeprowadzona automatycznie dla każdego pola nawet bardzo długiego formularza.

Odtwarzanie testu.Gdy test jest nagrany oraz dodano warunki sprawdzające popraw-ność można przejść do wykonania testu. Aby uruchomić test wystar-czy wcisnąć przycisk, który wywoła odtwarzanie zaznaczonych te-stów z wybranej ścieżki. Squish otwiera okno wybranej w ustawie-niach przeglądarki i wykonuje wszystkie nagrane akcje oraz spraw-dza warunki poprawności. Bardzo przydatna jest możliwość tworze-nia skryptów pozwalających na konfigurację uruchamianych testów. Dzięki temu możliwe jest wybranie interesujących grup testów oraz określenie pliku, do którego zapisywane będą raporty. Dla wykona-nego zestawu testu tworzony jest raport, w którym zawarta jest infor-

Rysunek 5. Mapa obiektów

6

Przetwarzanie

języka naturalnego

www.sdjournal.org Software Developer’s Journal 08/2007

macja o powodzeniu konkretnego testu oraz czasie wykonania – Ry-sunek 7.

Działanie testowanej aplikacji WWW może się nieco różnić w zależności od używanej przeglądarki. Sqiush for Web pozwala na sprawdzanie jak aplikacja zachowuje się na różnych przeglądarkach bez konieczności tworzenia różnych wersji testów na różne przeglą-darki.

Skrypt testujący nagrany z wykorzystaniem konkretnej prze-glądarki, może być odtwarzany na innych przeglądarkach, bez żad-nych dodatkowych modyfikacji. Skrypt taki nagrany za pomocą Fi-refoxa można bez problemu uruchomić używając Internet Explore-ra; wystarczy wybrać opcję, która decyduje o tym, jaka przeglądar-ka będzie wykorzystywana przy wykonywaniu testu. Podejście ta-kie umożliwia efektywne testowanie zgodności aplikacji z wieloma różnymi przeglądarkami. Możliwe jest również stosowanie instruk-cji warunkowej, która pozwala na wykonywanie różnych fragmen-tów skryptu dla różnych przeglądarek.

Testy Squish są niezależne również od systemu operacyjnego. Raz stworzony test może być z powodzeniem wykonywany w róż-nych systemach operacyjnych i to bez względu na to w jakim syste-mie operacyjnym i na jakiej przeglądarce został stworzony. Squish for Web wspiera uruchamianie i nagrywanie testów dla aplikacji we-bowych przy użyciu przeglądarek Microsoft Internet Explorer, Mo-zilla, Firefox, Apple's Safari i KDE's Konqueror na systemach Win-dows, Linux, Unix oraz Mac OS X.

W trakcie uruchamiania testów należy bezwzględnie pamiętać o zależności testowanej aplikacji od stanu bazy danych, którą ona wy-korzystuje. Jeżeli w czasie testu tworzone i zapisywane do bazy da-

nych są nowe dane (powstałe np. poprzez wypełnienie jakiegoś for-mularza) to każdorazowe uruchomienie testu będzie wiązać się z do-daniem tych samych danych – może to naruszać więzy integralności związane z unikalnością danych (np. nazwa klienta, nr faktury itp.). Jeżeli podczas testowania korzystamy z danych zapisanych w ba-zie danych wcześniej to pamiętać trzeba o tym aby dane użyte pod-czas nagrywania testu znajdowały się tam również podczas jego od-twarzania. Przykładowo, przy wykorzystywaniu list stronicowanych, zdarza się, że wymagane dane (np. nowo dodany wpis) w zależności od stanu bazy danych znajdują się na różnych stronach i nie są prawi-dłowo odnajdywane przez skrypt testujący i sygnalizowany jest błąd wykonania. Rozwiązaniem jest usuwanie nowo dodanych wpisów w ramach testu bądź odtwarzanie początkowego (sprzed testów) stanu bazy danych każdorazowo przed rozpoczęciem testowania.

Squish jest stosunkowo odporny na dokonywanie zmian w GUI testowanej aplikacji. Poszczególne pola mogą być przestawiane w ra-mach formatki, można dodawać nowe pola oraz elementy kontrol-ne, a zmiany te nie wpływają na poprawność wykonywania testów. Należy oczywiście pamiętać o uwzględnieniu nowych elementów w skrypcie, tylko wtedy testowana będzie poprawność ich działania.

Wsparcie dla innych rodzajów GUITwórcy Squish zadbali o wygodę i przyzwyczajenia użytkowników. Tworzony kod testu może być zapisany w różnych językach skrypto-wych; wybierać można pomiędzy językami Python, JavaScript i Tcl. Rozszerzanie nagranego skryptu pozwala na dodanie wielu cieka-wych funkcji i bywa czasem niezbędne.

Squish nie został stworzony jedynie z myślą o testowaniu aplika-

Rysunek 6. Skrypt testujący bezpośrednio po nagraniu

7www.sdjournal.orgSoftware Developer’s Journal 08/2007

cji webowych. Jego różne wersje pozwalają na automatyczne testo-wanie aplikacji zbudowanych w oparciu o różne technologie warstwy prezentacji. Squish for Qt pozwala tworzyć testy aplikacji stworzo-nych z wykorzystaniem biblioteki Qt przeznaczonej do projektowa-nia GUI w języku C++. Squish for Java współpracuje z aplikacjami zbudowanymi przy użyciu bibliotek graficznych dla środowiska Java, takich jak SWT (ang. Standard Widget Toolkit), Swing, RCP/Eclipse oraz AWT (ang. Abstract Windows Toolkit). Squish for Tk przezna-czony jest do współpracy z zestawem narzędzi graficznych Tk, opra-cowanym jako pakiet języka Tcl. Squish for KDE to specjalna, do-stępna bez opłat edycja Squish for Qt, pozwalająca na tworzenie au-tomatycznych testów GUI dla dystrybuowanych na otwartej licencji aplikacji KDE (Open Source/Free Software KDE applications). Squ-ish for XView oraz Squish for 4Js oferują wsparcie odpowiednio dla XView oraz klientów Four J's Genero. Istnieje także wersja Squish Educational przeznaczona dla uniwersytetów i innych instytucji zaj-mujących się edukacją, umożliwiająca studentom zdobycie praktycz-nego doświadczenia związanego z testowaniem graficznych interfej-sów użytkownika.

PodsumowanieWszystkich funkcji Squish nie sposób opisać w jednym artykule; można się z nimi zapoznać na stronie producenta oraz dzięki do-łączonemu do programu obszernemu podręcznikowi użytkownika, który je szczegółowo opisuje i pomaga rozwiązać wiele problemów.

Kilkumiesięczna praktyka stosowania Squish przyniosła wy-mierne korzyści. Zamieniła nastawienie do procesu testowania GUI aplikacji; nie jawi się on już jako bezproduktywne i niezbyt rozwija-jące powtarzanie tych samych czynności. Testy wykonują się w spo-sób automatyczny, a testerzy odpowiadają za kompletność repozyto-rium testów oraz jego poszerzanie o pojawiające się w aplikacji nowe funkcje oraz błędy zgłaszane przez klientów.

Wdrożenie automatycznych testów GUI jako uzupełnienie testów jednostkowych oraz testów komponentów wymiernie skróciło czas weryfikacji poprawności aplikacji przed wydaniem, przyspieszyło wydawanie kolejnych wersji oraz zmniejszyło ilość błędów w pro-dukcie (szczególnie tzw. błędów powracających, czyli poprawionych w przeszłości, i ponownie pojawiających się w nowych wydaniach).

Squish nie jest oprogramowaniem bezpłatnym, poniesione nakła-

dy zwracają się jednak szybko, a stosunek ceny do jakości powinien być zadowalający nawet dla wymagającego klienta.

Rysunek 7. Okno raportu wykonania testów

Bibliografia

• Narzędzie do testowania kodu Java – JUnit, dostępne w Internecie: www.junit.org

• Narzędzie do budowy projektu - Maven2, dostępne w Internecie: ma-ven.apache.org

• Martin Fowler „Continuous Integration”, dostępne w Internecie: www.martinfowler.com/ articles/continuousIntegration.html

• Jim Highsmith, „Extreme programming, Agile project management white paper”, Cutter consortium 2005

• Jason Gorman „Agile .NET Development Test-driven Development using Nunit”, dostępne w Internecie – www.parlezuml.com/tutorials/agiledotnet/tdd_nunit.pdf

• Narzędzie TestNG – dostępne w Internecie: http://testng.org/doc/• Strona firmy Froglogic – www.froglogic.com