Artykuły o technologiach IT, programowaniu, testowaniu i nie tylko

Automatyzacja testów aplikacji mobilnych nie jest tematem łatwym. Wiele osób rozpoczynając przygodę z tym zagadnieniem często poddaje się już na etapie konfiguracji środowiska. W poniższym artykule postaram się pokazać jak przejść praktycznie bezboleśnie przez ten etap oraz jak napisać swój pierwszy test dla aplikacji mobilnej.

Według statystyk najczęściej wykorzystywanych systemów operacyjnych za I kwartał 2017 opublikowanych przez serwis ranking.pl najbardziej popularnym systemem w Polsce jest obecnie Android.

rankingpl-chart

W dzisiejszych czasach trudno już sobie wyobrazić młodego człowieka nie korzystającego z telefonu komórkowego obsługiwanego przez jeden z wyżej wymienionych systemów operacyjnych na jego urządzeniu. Informacje te mają również bardzo duże znaczenie dla osób zajmujących się na co dzień testowaniem oprogramowania. Testowanie aplikacji mobilnych jest tematem coraz częściej poruszanym w świecie IT, a liczba ogłoszeń związanych z zatrudnieniem testerów aplikacji mobilnych stale rośnie.

Wraz ze wzrostem ilości aplikacji pojawia się coraz więcej narzędzi do ich testowania.  To co jeszcze kilka lat temu było trudne do przetestowania lub zautomatyzowania dzisiaj staje się dużo prostsze. Jednym z przykładów takich rzeczy jest np. automatyzacja testów aplikacji mobilnych. Dalsza część artykułu zostanie właśnie poświęcona jednemu z obecnie popularnych narzędzi wykorzystywanych podczas tworzenie zautomatyzowanych testów aplikacji mobilnych Appium.

Appium-icon

Appium jest narzędziem open-source służącym do automatyzacji testów aplikacji natywnych, webowych oraz hybrydowych na platformach iOS oraz Android przy wykorzystaniu standardu biblioteki WebDriver. W tym przypadku WebDriver został rozszerzony o specyficzne metody służące do testowania aplikacji mobilnych. Jedną z Istotnych cech Appium jest jego wieloplatformowość, która pozwala na pisanie testów na platformach iOS i Android przy pomocy tego samego API.

W zależności od systemu operacyjnego na jakim zamierzamy pisać i uruchamiać nasze testy Appium konfiguracja środowiska może przebiegać na kilka różnych sposobów. I tak w przypadku systemu klasy Windows poza instalacją JDK oraz Android SDK wystarczy pobrać i zainstalować Appium. W przypadku kiedy korzystamy z Linuxa instalacja może być nieco kłopotliwa. Aby jednak nie utrudniać sobie drogi do rozpoczęcia pracy skorzystamy z gotowego obrazu Appium który następnie uruchomimy w Dokerze.

Co będzie nam potrzebne aby rozpocząć automatyzację testów przy pomocy Appium?

Konfigurację środowiska rozpoczynamy od zainstalowania JDK oraz ustawienia zmiennej systemowej JAVA_HOME.

Kolejnym krokiem jest instalacja Android SDK. Tutaj podczas instalacji ważne jest aby dobrać odpowiednią wersję API, która będzie dopasowana do wersji na naszym urządzeniu. Innymi koniecznymi dodatkami jakie trzeba zainstalować to TOOLS oraz EXTRAS.

sdk-manager

Podobnie jak po instalacji JDK ustawiamy zmienną systemową ANDROID_HOME która będzie wskazywać na między innymi na główny katalog z SDK, tools oraz platform tools.

W celu sprawdzenia czy zostało to poprawnie wykonane możemy z linii poleceń wykonać:

Pierwsze dwa punkty listy mamy już za sobą, pora na pobranie obrazu Appium. Po zainstalowaniu dokera wykonujemy następujące polecenie:

Przed podłączeniem telefonu na którym zamierzamy wykonywać nasze testy należy włączyć tryb debugowania. W tym celu na telefonie przechodzimy do ustawień i wybieramy informacje o telefonie. Na samym dole klikamy kilka razy na numer kompilacji, po chwili otrzymamy informację że już jesteśmy programistą 🙂 Ostatnią czynnością jaką robimy na telefonie to wejście w opcje programistyczne oraz zaznaczenie opcji Debugowanie USB.

Teraz następnym krokiem będzie fizyczne podłączenie urządzenie oraz sprawdzenie czy jest ono widoczne przez ADB poprzez wykonanie:

Następnie instalujemy pobraną wcześniej aplikację Contact Manager na nasze urządzenie:

Zanim uruchomimy środowisko IntelliJ IDEA, spróbujmy jeszcze wyświetlić port na którym jest wystawiony nasz serwer Appium:

Teraz, kiedy mamy już postawiony serwer Appium wraz z przygotowanym urządzeniem gotowym do testów, napiszemy i uruchomimy pierwszy test. W tym celu uruchamiamy IntelliJ IDEA i tworzymy nowy projekt. Podczas tworzenia nowego projektu wybieramy moduł Maven. Po utworzeniu nowego projektu dodajemy zależności z których będziemy korzystać edytując plik POM znajdujący się w głównym katalogu naszego projektu. Dodajemy na początek takie biblioteki jak:

Podobnie jak w przypadku pisania testów pod aplikacje webowe i strony, podobnie tutaj na samym początku musimy nawiązać połączenie z serwerem (Appium). Przykładowy fragment kodu realizujący takie połączenie może wyglądać w taki sposób:

Jak widać, podczas tworzenia połączenia przekazywane są 2 rzeczy:

  • Adres serwera Appium
  • Lista parametrów wymaganych oraz opcjonalnych konfigurujących sposób pracy

Przykładowe parametry, jakie możemy wysyłać podczas realizacji takiego połączenia to np.:

  • Język jaki ma być ustawiony na emulatorze/urządzeniu testowym
  • Orientacja urządzenia (landscape/portrait)
  • Ścieżka do aplikacji która ma być instalowana i uruchamiana
  • Timeout dla kończenia połączenia kiedy serwer zbyt długo czeka na kolejne rozkazy

Oczywiście tych parametrów jest więcej, dokładną listę można podejrzeć tutaj. W dalszej części skupimy się bardziej na aplikacji, która już jest zainstalowana na naszym urządzeniu dlatego parametrami jaki musimy przekazać są deviceName, appPackage oraz appActivity.

O ile w przypadku deviceName wartość, jaką tam przekażemy nie będzie miała wpływu na to czy nasz test się uruchomi, to w przypadku appPackage oraz appActivity musimy nieco się wysilić. Metod na pobranie i wyświetlenie appPackage oraz appActivity jest kilka. Jedną z takich metod jest użycie aapt (Android Asset Packaging Tool), które powinno być dostarczone jako część narzędzi android SDK.
W celu podejrzenia informacji o appPackage oraz appActivity wykonujemy polecenie:

W odpowiedzi wyszukujemy fragmenty, które odpowiadają szukanym przez nas parametrom:

oraz

Jeśli na tym etapie pojawią się problemy lub jeśli chcemy skorzystać z innej opcji podejrzenia appPackage oraz appActivity, możemy wykorzystać prostą aplikację znajdującą się w Google Play – APK Info.

apk-info

 

Tutaj, po uruchomieniu aplikacji, wystarczy odszukać na liście nazwę aplikacji, która nas interesuje oraz wywołać na niej menu kontekstowe poprzez przytrzymanie. Następnie, po wybraniu detailed information oprócz podstawowych informacji, gdzie otrzymamy nazwę appPackage, pojawi się również lista dostępnych activity, których możemy używać w celu wywołania konkretnego widoku w naszej aplikacji.

Kiedy mamy już wszystkie potrzebne informacje, możemy rozpocząć pisanie pierwszego testu. W katalogu z testami dodajemy nową klasę. Nazwijmy ją na początek ContactManagerDemo. Przykładowy test sprawdzający czy lista kontaktów naszej aplikacji została wyświetlona wygląda następująco:

Jak widać na powyższym przykładzie, wykorzystaliśmy informacje, które wcześniej zebraliśmy – appPackage, appActivity oraz adres serwera Appium – 0.0.0.0:32768. Po uruchomieniu naszego testu na naszym telefonie powinna zostać uruchomiona aplikacja ContactManager.

===============================================
Default Suite
Total tests run: 1, Failures: 0, Skips: 0
===============================================
Process finished with exit code 0

Po zakończeniu testu aplikacja nadal będzie widoczna, ponieważ nie zakończyliśmy połączenia z serwerem. Możemy to zmienić dodając metodę, która wykona się po zakończeniu wszystkich testów w naszej klasie testowej:

Zwróćmy uwagę, że podczas tworzenia naszego testu pominęliśmy jeden z etapów pracy przy naszej aplikacji testowej, gdzie pobraliśmy informację o nazwie ID, który jest identyfikowany z listą kontaktów. Aby dobrać się do tej i innych informacji, które będą nam potrzebne podczas identyfikowania elementów naszej aplikacji, posłużymy się narzędziem uiautomatorviewer, które wchodzi podobnie jak aapt w skład narzędzi android sdk. Jeśli podczas próby uruchomienia uiautomatorviewera otrzymamy informację „No android devices were detected by adb” należy uruchomić lokalnie Android Debug Bridge poleceniem:

Może być również konieczne zatrzymanie serwera Appium który akturalnie wykorzystuje ADB, w tym celu chwilowo go zatrzymujemy

W celu upewniania czy wszystko jest ok możemy ponownie wydać polecenie adb devices.
uiautomatorviewer

Po uruchomieniu uiautomatorviewera wybieramy opcję Device Screenshot (uiautomator dump) w lewym górnym rogu i po chwili widzimy uruchomioną naszą aplikację. Poruszając się po okienku naszej aplikacji albo po drzewie elementów z prawej strony możemy wyciągnąć wszystkie niezbędne informacje, potrzebne do identyfikowania kolejnych elementów które użyjemy w naszych testach.

Lista przykładowych lokatorów wykorzystywanych przez Appium :

  • ClassName (class)
    driver.findElementByClassName(‚android.widget.EditText’);
  • AccessibilityId (content-description)
    driver.findElementByAccessibilityId(‚NavigateUp’);
  • Id (resource-id)
    driver.findElementById(‚login_button’);
  • Xpath (xpath)
    driver.findElementByXpath(“//android.widget.Button[@text=’zaloguj’]”);

Podobnie jak w przypadku Selenium, tak i w Appium wskazane jest, aby jak najczęściej stosować lokalizowanie elementów za pomocą ich ID. Jednak z doświadczenia nie zawsze jest to możliwe. Wtedy pomocne okazują się pozostałe opcje lub wariant ostateczny, jakim jest Xpath. Więcej ciekawych przykładów, jak konstruować uchwyty za pomocą Xpath można zobaczyć pod tym adresem.

Kiedy skończymy już pracę z uiautomatorviewerem możemy zakończyć lokalnie ADB poprzez adb kill-server oraz ponownie postawić nasz serwer appium – docker start appium. Można również upewnić się czy port na jakim teraz nasłuchuje nasz serwer nie zmienił się wykonując docker ps.

W następnej części artykułu napiszemy kilka testów naszej testowej aplikacji oraz zobaczymy jak wykorzystać do tego wzorzec Page Object Pattern.


Nawigacja