W jaki sposób testujemy aplikacje na Androida?

19 stycznia 2019 8 minut czytania

Witajcie ponownie — ostatnie dwa artykuły były nieco ciężkie, lecz daliście radę. Dzisiaj będzie coś lekkiego, bo pokażę Wam, w jaki sposób testujemy aplikacje mobilne. Zobaczycie, że zawód testera wcale nie jest taki prosty i tutaj również trzeba mieć odpowiednią wiedzę.

Kto zajmuje się testowaniem?

Wbrew pozorom odpowiedź tester wcale nie wyczerpuje tematu do końca. Oczywiście, testerzy są bardzo ważnym, lecz nie jedynym ogniwem w całym łańcuchu testowania. W kolejnych akapitach zobaczycie, że oprócz nich ważną rolę odgrywają też programiści, algorytmy, a także… roboty. Częściowe zastąpienie testerów manualnych maszynami jest logiczne. Każda roboczogodzina człowieka jest dość droga, a dodatkowo testy manualne są dość wolne. Jednak zawód testera nadal cieszy się dość dużym zapotrzebowaniem i na razie nic nie zwiastuje, żeby miało być inaczej, ponieważ są błędy, które tylko człowiek jest w stanie wykryć.

Jeśli chciałbyś nauczyć się testowania manualnego (a potem automatycznego), może zainteresować Cię oferta Coders Lab — Szkoły IT. Kurs na Testera Manualnego ukończysz w 2 tygodnie, a w trakcie przystąpisz do egzaminu, którego zaliczenie da Ci certyfikat ISTQB. Nauczysz się dobrych praktyk testerskich, poznasz narzędzia i środowisko pracy testera oraz odbędziesz pełny sprint Scrum. Tutaj przeczytasz szczegóły oferty, a póki co — lecimy dalej!

Testy jednostkowe — pierwszy szereg testów.

Testy jednostkowe są bardzo często lekceważone przez programistów, bierze się to przede wszystkim z lenistwa oraz niedoceniania ich wartości w projekcie. Bardzo często słyszałem zdania w stylu „Mamy testera w firmie, niepotrzebne nam testy jednostkowe”. Jest to oczywisty błąd, który może prowadzić do różnych problemów. Nie mogłem oprzeć się przed tym mini przemówieniem, wybaczcie, ale jestem fanatykiem testów jednostkowych (pół mieszkania za***ane testami, najgorsze). No dobrze, ale pewnie chcielibyście wiedzieć, co to są te testy jednostkowe? Jest to coś w rodzaju specjalnego kodu, który testuje inny kod. Domyślam się, że nie jest to najlepsza definicja w historii definicji, dlatego posłużę się życiowym przykładem.

Wyobraźcie sobie, że piszecie klasę weryfikującą poprawność jakiegoś formularza. W klasie tej znajduje się funkcja sprawdzEmail(). Możemy ją przetestować wypełniając formularz różnymi wartościami ręcznie i weryfikować czy wystąpił błąd, czy nie, takie rozwiązanie jest poprawne, lecz ma kilka wad. Za każdym razem, gdy ktoś wprowadzi jakieś zmiany w funkcji sprawdzEmail(), będziemy musieli powtarzać poprzednio wykonane testy, w celu zweryfikowania poprawności zmian. Do takiego przypadku idealnie nadają się testy jednostkowe. Wygląda to tak, że tworzymy specjalną klasę testową, która będzie inicjalizować naszą klasę weryfikującą formularz i uruchamiać jej metody z różnymi parametrami jednocześnie sprawdzając zwróconą wartość.

Dla naszej metody sprawdzEmail() możemy sprawdzać na przykład, czy metoda zwróci błąd w przypadku emaila bez znaku „@” i tak dalej. Zaletą takich testów jest przede wszystkim szybkość. Uruchomienie kilkuset testów jednostkowych to przeważnie kwestia kilku sekund. Dodatkowo ogromne znaczenie ma trwałość i powtarzalność – testy jednostkowe zawsze przetestują wszystko jednakowo dokładnie, dodatkowo raz napisane testy mogą nam służyć przez cały etap rozwoju projektu.

Automatyczne testy UI

typ programowania programisty

Automatyczne testy UI są jednymi z ciekawszych. Pisanie ich to również programowanie, jednak musimy zmienić nieco myślenie. W tym przypadku nie odnosimy się bezpośrednio do klas, lecz do konkretnych elementów interfejsu użytkownika. Testy te pisane są głównie przez testerów manualnych. Jest to dobra okazja, aby poczuć trochę programowania. Bardzo często zdarzała się sytuacja, że tester po pisaniu testów automatycznych przebranżawiał się na programistę, ponieważ spodobało mu się pisanie kodu.

Przejdźmy do praktyki — jak wygląda pisanie i wykonywanie testów automatycznych? Główną zasadą testów interfejsu użytkownika jest wyłapanie błędów, których nie jesteśmy znaleźć za pomocą testów jednostkowych. Dlatego tutaj nie testujemy walidacji formularza pod kątem różnych przypadków. Zamiast tego skupiamy się bardziej na elementach interfejsu użytkownika. Możemy przetestować na przykład, czy po wpisaniu błędnego e-maila wyświetli się nam komunikat z błędem.

Wykonywanie takich testów jest dość ciekawą sprawą, możemy je uruchomić na emulatorze lub smarfonie. W trakcie trwania testów symulowane są kliknięcia, w taki sposób jak robi to użytkownik. Jest to bardzo podobne do testów manualnych, z tym że trwa to nieco szybciej.

Testy integracyjne

Przeważnie nasza aplikacja łączy się z jakimiś zewnętrznymi usługami bądź serwisami. W takim wypadku oprócz testowania wyłącznie naszego kodu możemy sprawdzić, jak wszystko współgra z tymi zewnętrznymi usługami. Testy integracyjne powinny odbywać się po testach jednostkowych, więc zakładamy, że każdy element z osobna działa prawidłowo. Tutaj testujemy jedynie integrację wszystkich elementów, pomijając ich wewnętrzną implementację.

Najlepiej przedstawić to na przykładzie — wyobraź sobie, że masz aplikację mobilną, w której możliwe jest zakładanie kont użytkowników. W aplikacji wypełniasz formularz z danymi, który zostaje następnie przesłany na serwer, a w odpowiedzi serwer przesyła identyfikator oraz resztę danych nowo utworzonego użytkownika. Pisząc testy integracyjne, będziemy sprawdzać, czy konto zostało utworzone pomyślnie oraz czy dane otrzymane z serwera, odpowiadają tym które zostały przez nas wysłane. Oczywiście musimy zweryfikować też, czy format otrzymanych danych odpowiada dokumentacji.

Testy integracyjne są bardzo ważne, bo bez nich może dojść do sytuacji (tak jak na powyższym gifie), że pozornie wszystkie elementy projektu działają prawidłowo, ale nie potrafią się między sobą dogadać i w rezultacie dostajemy niedziałający produkt.

Testy manualne

programista android

Zapewne myśląc o testowaniu, większość ludzi ma właśnie na myśli testowanie manualne. Jest to tradycyjna metoda, polegająca na tym, że tester po prostu klika po naszym telefonie symulując specyficzne sytuacje, w których coś może pójść nie tak. Jednak wbrew pozorom nie jest to proste działanie. Dobry tester musi mieć nieco pojęcia o tym, w jaki sposób pisze się programy, aby wiedział gdzie szukać błędów. Tester powinien być kimś w rodzaju przeciwnika programisty, powinien za wszelką cenę próbować znaleźć w programie jakieś miejsce, w którym nie działa on prawidłowo. Dodatkowo tester manualny powinien świetnie znać wymagania oraz specyfikację aplikacji, ponieważ musi sprawdzić, czy zaimplementowane funkcjonalności są zgodne z wymaganiami klienta.

Testy penetracyjne

Testy penetracyjne wykonywane są przeważnie przez specjalistów z zewnętrznych firm. Jest to coś w rodzaju audytu, mającego wskazać miejsca podatne na różnego rodzaju ataki. Podczas takiego testu przeprowadzana jest kontrolowana próba ataku i znalezienia dziur mogących narazić użytkowników na niebezpieczeństwo. Efektem takich testów jest raport pokazujący odnalezione błędy wraz z zaleceniami pomagającymi zniwelować zagrożenie związane z odnalezionymi błędami.

Co z tymi robotami?

Wspomniałem na początku, że aplikacje mogą testować również roboty. Historię usłyszałem od swojego znajomego, który pracował w dość dużej firmie. Rozwijali oni aplikację, która była już bardzo stara (powstała tuż po przedstawieniu Androida). Po takim czasie łatwo można sobie wyobrazić, jaki tam panował bałagan. Kod był napisany w tak prymitywny sposób, że nie dało się go przetestować testami jednostkowymi i automatycznymi. Dlatego firma zdecydowała o zaprogramowaniu robotycznego ramienia w celu przeklikiwania aplikacji w poszukiwaniu błędów. Dla mnie jest to dość abstrakcyjne, jednak jestem sobie w stanie to wyobrazić, bo już nie jeden głupi pomysł w swoim życiu widziałem.

Tym sposobem dotarliśmy do końca dzisiejszego odcinka. Jeśli czyta to jakiś profesjonalny tester, to zachęcam do komentowania. Być może z jego perspektywy niektóre rzeczy wyglądają nieco inaczej niż z perspektywy programisty. Oczywiście rodzajów testów jest znacznie więcej, niż tutaj wymieniłem, ale te wymienione przeze mnie są praktykowane w większości, nawet tych mniejszych firm. Dzięki za dziś i widzimy się już za tydzień, kiedy to opowiem Wam jakie zabezpieczenia stosujemy w aplikacjach na Androida. Zapraszam również do pisania w komentarzach tematów, o których chcielibyście poczytać w ramach tej serii. Do zobaczenia!

Zapraszam również na największe w Polsce forum dla programistów Android. Jeśli macie pytania odnośnie do kariery programisty — zapraszam do działu Kariera programowanie. Zachęcam również do przejrzenia działu Praca oraz zlecenia dla programistów — być może to właśnie tam znajdziesz swoją pierwszą pracę.

Poprzednie odcinki:

Artykuł powstał we współpracy z Coders Lab