ATSuite – testerzy nie muszą kodować by automatyzować? Oceniamy!

Wprowadzenie do narzędzia

ATSuite jest dostarczone w formie zestawu bibliotek i interpretera, który odpowiada za uruchomienie testów. Śmiało można cały ten zestaw nazwać frameworkiem testowym, wykorzystującym własny język skryptowy do tworzenia skryptów automatycznych. I tu pojawia się pierwsze zagrożenie. Stworzenie zupełnie nowego języka skryptowego rodzi pytania o jego jakość, stabilność i utrzymanie. Rozwój każdego języka silnie związany jest z jego grupą wsparcia. Jest więc poważnym ryzykiem wdrażać rozwiązanie, za którym stoją pojedyncze osoby, i które za kilka miesięcy może przestać być wspierane. Może zabraknąć poprawek do luk i defektów. ATSuite jest rozwiązaniem freeware, a więc darmowym, ale bez prawa modyfikowania kodu.

Chcielibyśmy na samym początku zaznaczyć, że według producentów narzędzie zostało stworzone z myślą o pracownikach zespołów testów nieposiadających doświadczenia w programowaniu, więc nasze testy bazują na wcieleniu się w takich użytkowników. Podczas korzystania z aplikacji napotkaliśmy problemy, które w naszej opinii, dla testerów niemających kompetencji programistycznych nie byłyby możliwe do rozwiązania. Część rzeczy musimy więc opisać z punktu widzenia bardziej doświadczonych programistów i testerów automatycznych.

Przygodę z ATSuite należy rozpocząć na stronie internetowej twórców aplikacji, gdzie mamy możliwość pobrania narzędzia oraz dokumentacji, która dla początkujących użytkowników będzie podstawowym wprowadzeniem. Krok po kroku poprowadzi nas do napisania pierwszego testu. Na stronie możemy zapoznać się również z możliwościami narzędzia, które według producentów pomoże nam w automatyzacji testów aplikacji webowych i desktopowych poprzez szereg funkcji znanych z Selenium, Sikuli, JAVA oraz MonteMediaLibrary. Połączenie możliwości tych rozwiązań w jedno narzędzie wydaję się karkołomnym pomysłem.

Ze strony producenta należy pobrać skompresowany plik z narzędziem oraz dokumentacją. Polecamy zapoznać się z dostarczonym opisem. Sama dokumentacja w wersji podstawowej jest bardzo czytelna i zawiera wszystkie potrzebne informacje do rozpoczęcia pracy.

Instalacja narzędzia polega na rozpakowaniu skompresowanego pliku w wybranym przez siebie miejscu. Po rozpakowaniu widzimy plik JAR odpowiedzialny za interpretowanie naszych skryptów oraz katalog lib zawierający biblioteki potrzebne do działania narzędzia. W dalszej kolejności dowiadujemy się o wymogu zainstalowania platformy JAVA. Zakładając użytkownika, który nie ma poważniejszej wiedzy w temacie pobieramy najnowszą dostępną i stabilną wersję. Po parunastu minutach mamy w pełni zainstalowane środowisko testowe i możemy rozpoczynać procedurę tworzenia skryptów testowych.

Aktualnie dostępna wersja oprogramowania to 1.0.1. W naszym wypadku część testów (głównie dla OCR) była wykonywana na wcześniejszej wersji narzędzia (1.0.0) ze względu na brak możliwości wykorzystania tychże funkcjonalności na wersji obecnej (1.0.1). Tutaj ujawnił się poważny defekt frameworku. Jeżeli będziecie chcieli wykorzystać funkcjonalności dostępne w Sikuli i Selenium w jednej wersji ATSuite, musicie poczekać aż twórcy poprawią ten defekt.

Dodatkowym krokiem w rozpoczęciu pracy z narzędziem jest zainstalowanie edytora tekstu, w którym będziemy tworzyć / edytować nasze skrypty. Oczywiście można wykorzystać standardowy notatnik, ale my posiłkujemy się rozwiązaniem Notepad++, które świetnie spisuje się przy pracach tego typu.

Pierwszy test automatyczny

Pierwszym krokiem w stworzeniu własnego skryptu testowego będzie skonfigurowanie sterownika przeglądarki, która będzie wykorzystywana do testów. ATSuite deklaruje wsparcie dla przeglądarek Firefox, Chrome, Internet Explorer oraz Safari. Po odpowiednim skonfigurowaniu – wybraniu, z jakiej przeglądarki chcemy skorzystać, możemy rozpocząć pisanie dalszych instrukcji. Następnym krokiem jest wskazanie strony internetowej do testów, na której będziemy wykonywać czynności testowe. Dodatkową opcją jest możliwość powiększenia otwartego okna przeglądarki tak, by przeprowadzać testy w realnych warunkach, w jakich pracują użytkownicy. Składnia skryptu do przygotowania środowiska testowego wydaje się więc prosta i logiczna.

Mamy już początkowy kod naszego testu, który na pierwszy rzut oka wydaje się banalny. Pierwszym działaniem, jakie chcielibyśmy wykonać na stronie jest kliknięcie elementu. Aby jednak wykonać działanie na elemencie należy go na początku wskazać. Narzędzie daje nam tutaj duże możliwości w identyfikacji elementu poprzez metodę find. Umożliwia ona odnalezienie elementu poprzez jego atrybuty, tj. id, name, xpath, itp. Gdy uda nam się odnaleźć element na stronie możemy wykonać na nim dowolną akcję. Jest to nie tylko proste klikanie, ale również inne akcje, jak chociażby w naszym skrypcie wypełniania formularza, gdzie wszystkie pola uzupełniamy tekstem.

W ten sposób mamy w pełni zautomatyzowane wysyłanie formularza na stronie, może poza captchą, ale automatycy wiedzą, że tu bez wsparcia programistów nie będzie łatwo o automat. Do uzyskania pełnego testu brakuje tylko weryfikacji. Oczywiście po wykonaniu czynności w interfejsie należy zweryfikować, czy system zareagował tak jak powinien. Do weryfikacji możemy użyć jednej z wielu metod, gdzie sprawdzamy czy dane pole lub element spełniły wybrany warunek.

Nasz test jest gotowy. Nie jest to może skomplikowany skrypt testowy natomiast można uznać, że dla osoby, która nigdy wcześniej nie programowała może to być całkiem spore osiągnięcie. Pozostało jeszcze tylko uruchomienie skryptu.

Uruchamianie skryptu odbywa się za pomocą polecenia wykonywanego w konsoli systemowej. W poleceniu wskazujemy plik JAR narzędzia oraz napisany skrypt. Wszystko przebiegło bardzo szybko, przeglądarka się uruchamia, wykonują się czynności napisane w skrypcie, a na końcu przeglądarka zostaje zamknięta. W wyniku testu został wygenerowany zestaw plików z logami przejścia testu oraz informacjami na temat weryfikacji wykonanych podczas testu. Uruchamianie testów można sobie ułatwić poprzez napisanie pliku BAT odpowiedzialnego za uruchamianie testów z wcześniej zdefiniowanymi parametrami.

Zalety i wady

Łatwość pisania skryptów w testowanym narzędziu oceniamy bardzo wysoko głównie z powodu naprawdę prostej składni i intuicyjnej sekwencji akcji wykonywanych w ramach testu. Natrafiliśmy jednak na problemy, które jak się okazało, wymagały trochę większej wiedzy niż się spodziewaliśmy. Należy podkreślić, że wymaganą umiejętnością do korzystania z ATSuite jest również znajomość Firebuga i Firepatha. Bez nich korzystanie z testowanego narzędzia będzie katorgą. Można oczywiście założyć, że każdy tester testujący aplikacje webowe taką wiedzę powinien posiadać, natomiast z naszego doświadczenia wiemy, że tak nie jest. Kolejnym problemem, który dla osób niemających doświadczenia z takimi narzędziami bądź też z programowaniem w języku JAVA jest sposób prezentacji błędów podczas wykonywania testu. Niestety wyjątki będące komunikatami niepowodzenia skryptu są dla mniej doświadczonych użytkowników nieczytelne. To z kolei może skutkować tym, że poprawa skryptu może stać się niemożliwa. Skoro nie wiemy, co się zepsuło, to nie wiemy, co naprawić. Problem wydaje się być skomplikowany ze względu na specyfikę języka JAVA. My natomiast zachęcamy twórców, aby poprawili formę prezentacji błędów tak, by osoby bez doświadczenia również mogły sobie poradzić w poprawianiu skryptów.

Kolejny problem to brak możliwości uruchomienia testów na wszystkich wspieranych przeglądarkach internetowych. Domyślnie narzędzie powinno umożliwić wykonanie testów w przeglądarkach Firefox, Chrome, Internet Explorer i Safari. Podczas testów okazało się, że wykonanie skryptów na przeglądarce Internet Explorer w systemie operacyjnym Windows 8.1 jest niemożliwe – test się rozpoczyna, okno przeglądarki się otwiera, lecz chwilę później w konsoli otrzymujemy pokaźny zestaw błędów i test jest przerywany. Błąd był weryfikowany na Windowsie 7 i stwierdzono, że na tym systemie nie występuje. Później okazało się, że podobny problem występuje również z przeglądarką Safari z tą różnicą, że nie działa ona na wszystkich systemach z jakich korzystaliśmy. Niestety IE i Safari nie są, jak deklarują twórcy, wspierana w testach.

Wyżej wymienione problemy to te najbardziej krytyczne. W dalszych testach już nie znaleźliśmy ich więcej. Natrafiliśmy za to na problemy czytelności generowanych logów z wykonania testów. Nie jest to może wyjątkowo nieprzyjazne użytkownikowi zachowanie aplikacji natomiast nazewnictwo raportów w formie execution-10-06-145707 nie mówi użytkownikowi nic na temat testu, którego raport dotyczy. Dużo lepszym rozwiązaniem byłoby umieszczenie w nazwie pliku nazwy testu. Kolejną dobrą praktyką mogłoby być generowanie raportu z wykonanych testów tylko w przypadku, gdyby w teście weryfikacje były wykonywane. Aktualnie raporty są generowane przy każdym uruchomieniu testów nawet, gdy żadnej weryfikacji w teście nie ma. Będzie to miało przełożenie na wydajność działania frameworku przy większej ilości testów.

Możemy potwierdzić, że z aplikacji korzysta się bardzo przyjemnie i spokojnie można ją polecić osobom, które dopiero rozpoczynają swoją przygodę z automatyzacją testów. Natomiast jako użytkownicy doświadczeni musimy przytoczyć inne przykłady nie do końca przemyślanego rozwiązania w tym narzędziu. Na pewno zwróciliście uwagę na wykonywane w naszych testach wyszukiwanie elementów i wykonywania na nich akcji. Ilekroć chcemy wykonać akcję na danym elemencie nie w sekwencji, czyli w międzyczasie wykonując działania na innych elementach, musimy ponownie go wyszukać. Przeszukanie wielokrotnie całej strukturę DOM w poszukiwaniu tego samego elementu na pewno stawia wydajność skryptu pod dużym znakiem zapytania.

Jedną z funkcjonalności naszego testowanego narzędzia jest możliwość automatyzacji czynności testowych dla aplikacji desktopowych. Problem jaki napotkaliśmy to to, że w dokumentacji praktycznie nic w temacie testów aplikacji desktopowych nie ma.  Funkcji da się domyślić bazując na doświadczeniu z rozwiązań na jakich bazuje ATSuite, ale dla osób niedoświadczonych prawdopodobnie będzie to przeszkoda nie do pokonania. Wszystkie akcje (a jest ich na razie niewiele) bazują na małym fragmencie funkcjonalności Sikuli. Działania wykonywane są na zasadzie rozpoznania obrazka podanego w skrypcie i porównania go z tym, co znajduje się na ekranie. Po odnalezieniu elementu wykonywana jest akcja na tymże znalezionym elemencie – np. klikanie, drag and drop, itp.. I tu pojawia się poważny kłopot tak rozumianej automatyzacji. Każda czynność, jaką chcieliśmy zautomatyzować wiązała się z robieniem zrzutu ekranu, wycinaniem konkretnego obrazka i definiowaniu akcji na nim. Nie wszystkie czynności udało się nam zautomatyzować, a niektóre okazały się tak skomplikowane, że napisanie automatu dla prostego przejścia zajmowało godziny.

Wady rozwiązania nie powinny jednak przysłaniać jego zalet. Jest to wspomniana wcześniej łatwość pisania i czytelność testów, które, w naszej opinii, są ogromną zaletą. Testowany język skryptowy oferuje dużo możliwości związanych z tworzeniem dokumentacji testowej. Jej tworzenie odbywa się za pośrednictwem odpowiednich komentarzy w formie adnotacji, które dostarczają opis wykonywanych działań. Funkcjonalność ta jest bardzo przydatna, gdy chcemy po każdym teście otrzymać odpowiednio wygenerowany plik raportu z przeprowadzonego testu. Pliki generowane są w postali XML, co również daje duże możliwości w edycji oraz imporcie do narzędzi zarządzania testami.

Kolejnym ciekawym rozwiązaniem jest możliwość tworzenia procedur, które będą odpowiedzialne za uruchomienie często powtarzanych czynności. Umożliwia to uproszczenie skryptów i zautomatyzowanie sekwencji wybranych akcji. Zdefiniowane procedury można uruchamiać wielokrotnie, przez co zmniejszamy ogólną ilość instrukcji w skrypcie. Zdecydowanie polepsza to  możliwości utrzymania skryptów.

Tworzone przez nas skrypty mogą z czasem stawać coraz bardziej złożone i cały czas powinniśmy mieć świadomość że można zrobić coś bardziej optymalnie. Jak w większości innych języków skryptowych również tutaj mamy możliwość wykorzystania pętli i instrukcji warunkowych. Oczywiście nie każde testy wymagają wykorzystania takich elementów natomiast z doświadczenia wiemy, że im nasza droga w automatyzacji będzie dłuższa tym częściej będziemy do nich sięgać. Sterowanie logiką i wykonaniem czynności w odpowiedniej kolejności oraz definiowanie ilości wykonań w skryptach będzie prędzej czy później bardzo przydatne. Język daje więc wsparcie również użytkownikom bardziej zaawansowanym.

Dla użytkowników wykorzystujących dużą ilość danych testowych ATSuite również oferuje możliwość wykorzystania bazy danych i pobranie z niej danych, wykorzystanych później do data-driven. Język ma również możliwość generowania pseudolosowych danych liczbowych oraz dat, które mogą być wykorzystywane w testach. 

Ciekawym i dość pożytecznym rozwiązaniem jest możliwość definiowania zmiennych, które możemy wykorzystywać podczas testów. Zmienne takie mogą być definiowane jako globalne lub lokalne w zależności od zapotrzebowania. Wszystkie czynności związane z obsługą zmiennych również są dostępne, tak więc inkrementacja czy dekrementacja wartości liczbowych nie będzie żadnym problemem. Problematyczna dla bardziej zaawansowanych użytkowników może być składnia i odwoływanie się do zmiennych (w dość niecodzienny sposób) z dwoma dwukropkami przed nazwą. W większości języków programowania takie rozwiązanie byłoby nie do pomyślenia.

Na sam koniec chcielibyśmy wspomnieć dwie typowe, ale ważne funkcje narzędzia. Pierwsza, dość oczywista, związana z możliwością wykonywania zrzutów ekranu w momencie zdefiniowanym w teście. Łatwo możemy wykonać zrzut i wykorzystać go do zgłoszenia incydentu lub po prostu porównania z innymi zrzutami. Drugą funkcją jest możliwość nagrywania filmów z przebiegu testów. Nie trzeba więc wykorzystywać specjalnych dodatków do przeglądarek albo narzędzi, które nagrywają to, co się dzieje u nas na ekranie. ATSuite ma możliwość nagrania przebiegu całego testu. Nagrane filmy oczywiście można wykorzystać do weryfikacji przebiegu testu lub chociażby, jako filmy instruktażowe z obsługi aplikacji – możliwości jest wiele.

Podsumowanie

Nasze testy nie dotknęły całego języka, więc nie zbadaliśmy jego poprawności działania w całym spektrum funkcji. Jednak to, co w ramach skończonego czasu udało się sprawdzić, jest dla nas wystarczającą podstawą do pozytywnej oceny narzędzia. Szczególnie jeśli weźmiemy pod uwagę to, że aplikacja została udostępniona za darmo. Z zainteresowaniem będziemy obserwowali rozwój tego rozwiązania. Wspomniane przez nas problemy są raczej łatwe do poprawy, a całościowo architektura jest dość dobrze przemyślana. ATSuite ma potencjał, ale musi być ciągle rozwijany, a napotkane problemy muszą być usuwane. 

Na dzień dzisiejszy nie polecilibyśmy go jako samodzielnego narzędzia do budowania automatyzacji w organizacji. Polecamy je natomiast do płynnego przejścia od prostego testowania manualnego do częściowo zautomatyzowanego i jako zachętą do bliższego poznania Selenium WebDrivera czy Sikuli, na których to bazuje. ATSuite ma potencjał przekonania testerów manualnych do pójścia w kierunku automatyzacji poprzez swoją prostotę, czytelność i łatwość wykorzystania.

Plusy:

• szybkie rozpoczęcie w automatyzacji
• prostota i czytelność skryptów
• duże możliwości w bardziej złożonych zadaniach testerskich
• dość obszerna dokumentacja
• wsparcie.

Minusy:

• problemy z konfiguracjami
• przejście pewnych etapów uczenia się narzędzia wymaga szerokiej wiedzy i doświadczenia w automatyzacji
• problemy w działaniu niektórych funkcji w zależności od wykorzystywanej wersji.