Automatyczne testy aplikacji mobilnych cz.3 | Blog X-Coding
automatyczne-testy-aplikacji-mobilnych-cz-3

Automatyczne testy aplikacji mobilnych cz.3

30.06.2017 / / Developers

W dzisiejszym wpisie kontynuujemy zagadnienie automatyzacji testów aplikacji mobilnych.

Na czym polega pisanie testów automatycznych?

Dla wielu osób spoza środowiska IT systemy informatyczne biorą się jakby „z powietrza”. Świetnie pokazuje to następujący schemat:

Jak wygląda testowanie To naprawdę działa inaczej (źródło: https://thenextweb.com/wp-content/blogs.dir/1/files/2009/10/13449_full.jpg)

Tak samo jest w przypadku testów automatycznych. Za każdym testem stoi pewna historia (user story). Następnie przekłada się ona na listę kolejnych działań w aplikacji. Działania przekładają się z kolei na „kliknięcia przycisków”. Na podstawie tych kliknięć możemy tworzyć testy automatyczne. Czy to oznacza, że testować możemy tylko za pomocą kliknięć? Oczywiście, że nie. Wprawdzie niektóre narzędzia ograniczają się tylko do tego, ale testy mogą sprawdzać zachowanie aplikacji również w sytuacjach, na które użytkownik nie miał bezpośredniego wpływu. Przykładem takiego testu może być sprawdzenie, co się stanie, kiedy do użytkownika zadzwoni telefon podczas używania aplikacji.

Narzędzia

Na rynku jest wiele dostępnych narzędzi wspomagających pisanie i uruchamianie testów automatycznych. Należą do nich między innymi:

  • Appium – narzędzie open source, które pozwala na automatyzację aplikacji natywnych, webowych oraz hybrydowych,
  • UIAutomator – framework Googla, który pozwala na testowanie natywnych aplikacji (od API 18) oraz daje dostęp do procesów systemowych,
  • Robotium – również przeznaczony jest do testowania natywnych (Android) i hybrydowych aplikacji. Cytując oficjalny profil projektu na GitHubie: „Pozwala w prosty sposób na pisanie potężnych testów typu black-box”.

Część narzędzi do testów automatycznych to po prostu biblioteki do języków programowania. W przypadku Androida są to biblioteki Javowe. Pozostałe narzędzia umożliwiają nagrywanie zachowania — ruchu na ekranie — a następnie odtworzenie go w ramach testów. Wróćmy jednak do pierwszej grupy. Wyobraźmy sobie, że mamy aplikację z logowaniem i pewną testową parę loginu i hasła – te dane posłużą nam do sprawdzenia testu. Nasz widok składa się z dwóch pól EditText i przycisku zaloguj. Jak wygląda test logowania np. w Robotium?

public class LoginActivityTest extends ActivityInstrumentationTestCase2<LoginActivity> {

   private Solo solo;

   public LoginActivityTest() {
       super(LoginActivity.class);
   }

   public void setUp() throws Exception {
       solo = new Solo(getInstrumentation(), getActivity());
   }

   public void testLogIn() throws Exception {

       solo.enterText(0,"login");
       solo.enterText(1,"password");
       solo.clickOnButton("Zaloguj");

       Assert.assertTrue(solo.searchText("Logowanie pomyślne"));

   }

   @Override
   public void tearDown() throws Exception {
       solo.finishOpenedActivities();
   }

}

Analogicznie możemy — i nawet powinniśmy — napisać test, który sprawdzi, czy w przypadku błędnego hasła logowanie się nie powiodło. Dobre praktyki w testowaniu to jednak temat na oddzielny artykuł. Jest pełna dowolność w tworzeniu testów automatycznych. Można testować każdy ekran osobno, dzięki czemu bardzo szybko można „przemielić” ekran, na którym coś przestało działać. W przypadku testów manualnych należałoby przygotować osobne apk, żeby ograniczyć do minimum ilość kliknięć potrzebnych do sprawdzenia wszystkich kombinacji.

Testy a Google

Nie tak dawno na łamach naszego forum opisywaliśmy jak podłączyć się do Firebase. Zachęcam do zapoznania się jeszcze raz z artykułem. Przybliżę teraz inne narzędzie z tej konsoli, a mianowicie Test Lab.

Firebase umożliwia uruchamianie własnych testów, napisanych z użyciem którejś z bibliotek. Aby to zrobić, musimy wpierw spakować apk z aplikacją oraz osobne apk z testami. Następnie należy umieścić oba pliki na serwerze, wybrać docelowe urządzenia do przetestowania, a po zakończeniu wykonania testów otrzymamy wyniki. W przypadku aplikacji natywnych możemy również uruchomić test Robo. Taki test uruchamia naszą aplikację w formie drzewa i sprawdza wszystkie ścieżki, do których może dotrzeć.

W darmowym planie można wykonać 10 testów dziennie. Nie jest to dużo, ale na indywidualne potrzeby i szybkie reagowanie powinno wystarczyć. Nawet taka mała ilość przydaje się, gdy otrzymamy powiadomienie (też z Firebase), o błędzie u któregoś z użytkowników. Sam Firebase oprócz przechwytywania zdefiniowanych błędów i komunikatów, zbiera również informacje o nieprzewidzianych błędach. Korzystając z zapisanej zawartości stosu, jesteśmy w stanie znaleźć wadliwy ekran i uruchomić testy dla tego ekranu – i to wszystko bez zaawansowanej infrastruktury szybkiego reagowania.

Podsumowanie

Testy automatyczne mogą budzić kontrowersje, w szczególności ze względu na wyższy koszt wdrożenia. Niemniej jednak, stosując je mądrze, można zyskać, dzięki zwiększeniu jakości kodu i stosunku pokrycia go testami.