Testing

Nie taki diabeł straszny, jak go malują – czyli testy aplikacji mobilnych

Czerwiec 15, 2016 0
Podziel się:

Wraz z postępem technologii zmienia się model korzystania z Internetu, dostępu do rozrywki czy wykorzystywania informacji. Kiedyś źródłem wiedzy były książki, potem gazety dziś zaś nowe technologie. Komputer przestał przodować w zakresie szeroko pojętej nowoczesności – obecnie prym wiodą urządzenia mobilne stanowiące dla Nas okno na świat. Ponieważ aplikacji na rynku jest wiele i konkurencja nie śpi, należy więc zadbać o jakość rozwijanych produktów i przyjrzeć się lepiej zasadom testowania aplikacji. Dzisiaj pochylimy się nad stworzeniem testu funkcjonalnego przykładowej aplikacji mobilnej na platformę iOS z wykorzystaniem SeeTest Automation. Opis oraz zalety tego narzędzia przedstawiłam we wcześniejszym wpisie, do  zapoznania z którym serdecznie zapraszam.

Wstęp

Aby rozpocząć pracę z SeeTest Automation należy zainstalować także dodatkowe środowisko w zależności od tego, w jakim języku chcemy pisać testy. Może być to Eclipse, Visual Studio, IntelliJ, JetBrains, HP QTP itd. Oprócz tego należy posiadać podłączone urządzenie do komputera. Oczywiście można także korzystać z emulatora, ale na potrzeby niniejszego artykułu skorzystamy z realnego urządzenia podłączonego przez kabel USB. Ponieważ test tworzony będzie na platformę iOS, tak więc dodatkowo posiadam zainstalowany iTunes, aby było możliwe podłączenie urządzenia od Apple’a. Przy pierwszym podłączeniu iPhone’a lub iPada do komputera i próbie otworzenia widoku ekranu telefonu, na urządzeniu zostanie zainstalowana aplikacja dodatkowa, tzw. Bridge. Umożliwi to przesyłanie komend z Clienta do urządzenia. Dodatkowo przed przystąpieniem prac należy wysłać do firmy Experitest prośbę o stworzenie pliku administracyjnego. Jest to tzw. provisioning profile dla Clienta, aby mógł on wykorzystywać pełną kontrolę nad telefonem. Szczegóły dotyczące tego kroku znajdują się w sekcji „Connecting an iOS Device” na stronie dokumentacji.

Praca z Clientem

Kiedy wszystkie niezbędne programy są już zainstalowane oraz gdy poprawnie skonfigurowaliśmy urządzenie, możemy teraz przejść do samego SeeTesta. W sekcji „Application” należy zaimportować builda aplikacji. Dla iOS będzie to plik z rozszerzeniem .ipa, dla Androida będzie to .apk zaś dla Windows Phone’a .xap lub .appx . Podczas importu SeeTest sam zapyta czy chcemy od razu zainstalować aplikację na wybranym urządzeniu oraz czy ją uruchomić. Aplikacja może zostać uruchomiona w dwóch trybach: instrumented oraz non-instrumented. Tryby te różnią się atrybutami, które jesteśmy w stanie zaczytać z kontrolek przy pomocy object spy. Podczas pracy z Clientem aplikacja uruchamiana jest zawsze w trybie instrumented, ale można to zmienić ręcznie lub w kodzie.

Aby otworzyć okienko z zrzutem ekranu urządzenia należy w panelu Device dwukrotnie kliknąć na nazwę urządzenia lub na ikonkę telefonu z żółtym znaczkiem.

Device and Application Management

Device and Application Management

Kiedy uruchomiliśmy już aplikację na urządzeniu i mamy otwarty widok pulpitu telefonu możemy przejść do nagrywania testu i analizy wygenerowanego kodu.

Projekt w SeeTest

Właściwy, miarodajny test, z którego płynie wiele korzyści uzyskamy wówczas, gdy rozpoczniemy prace nad nim od nagrania kilku stepów w Cliencie a następnie wygenerowany kod przeniesiemy do dowolnego innego narzędzia i w nim rozpoczniemy prace modernizacyjne.

Na potrzeby niniejszego artykułu skorzystałam z gotowej, dostarczanej razem z SeeTest’em aplikacji na iOS – EriBank. Scenariusz testu jest prosty – wpisując niepoprawne dane 3 razy chcę sprawdzić, czy aplikacja mnie nie zaloguje oraz wpisując poprawne dane chcę sprawdzić czy uda mi się zalogować. Wszystkie czynności wykonane w aplikacji nagrywam aby zidentyfikować jak najwięcej obiektów, przydatnych do weryfikacji poprawności wykonanych operacji. Wybranym przeze mnie językiem, w którym chcę aby został wygenerowany kod jest Java połączona z TestNG.

Aby rozpocząć nagrywanie testu należy nacisnąć czerwony przycisk Record, poczekać aż Client zainicjuje wszystkie potrzebne mechanizmy,  a następnie zacząć klikać w aplikacji, aby nagrały się wszystkie wykonane akcje. Po zakończeniu wszystkich kroków należy kliknąć w niebieski kwadrat aby zapisać nagrane stepy oraz wygenerować kod. W pasku wyboru w Code Area mamy możliwość zdefiniowania języka programowania, w którym chcemy otrzymać poszczególne kroki. Możemy je dowolnie modyfikować w Command Area a zmiany dynamicznie ukażą się w kodzie poniżej. Obiekty ­– ikony – w które klikaliśmy, zostaną automatycznie dodane do defaultowego repozytorium. Możemy je dowolnie modyfikować – zmieniać nazwy, parametry po których chcemy je rozpoznawać.

Command Area and Code Area

Command Area and Code Area

Repozytorium obiektów

Repozytorium obiektów

  • Rozpoznawanie obiektów

SeeTest umożliwia rozpoznawanie obiektów na 4 sposoby: Native, czyli po atrybutach natywnych (name, accessibilityLabel, xpath, id itd.); Web, czyli po atrybutach typowo webowych dla webowych aplikacji (xpath, class, css itd.); Image – porównywanie na podstawie bitmapy oraz Text – rozpoznawanie opiera się na algorytmie OCR (Optical Character Recognition), który wybiera tekst z obrazka. Więcej informacji tutaj.

Edycja obiektu - możliwe sposoby rozpoznawania

Edycja obiektu – możliwe sposoby rozpoznawania

Kiedy mamy nagrany test oraz wybraliśmy odpowiedni dla nas język to jest to czas, aby przejść do wybranego narzędzia, w którym powstanie właściwy test. Na potrzeby artykułu używam Eclipse Mars. Tworzę nowy projekt javovy, dodaję wszystkie niezbędne biblioteki, tj. testng, jcommander oraz biblioteki ze ścieżki C:\Program Files(x86)\Experitest\SeeTest\clients\java (domyślna ścieżka gdzie zainstalowany jest SeeTest). Dodaje nową klasę i kopiuję do niej kod wygenerowany przez Clienta. Przed testem tworzona jest nowa instancja Clienta, ustawiana jest ścieżka do repozytorium obiektów, z której Client ma korzystać do rozpoznawania kontrolek, ustawiany jest reporter, urządzenie oraz aplikacja jest uruchamiana na urządzeniu. projectBaseDirectory – jest to ścieżka do repozytorium obiektów w naszym projekcie SeeTest’owym.

BeforeTest

BeforeTest

Następnie uruchamiane są dwa testy, w kolejności zgodnej z priorytetem. invocationCount – jest to parametr pochodzący z testNG i oznacza ilość, jaką dany test ma się wykonać. Jako 2 parametr metody elementSendText() podaje się nazwę kontrolki – taką samą jak w repozytorium Clienta.

Metody testowe

Metody testowe

Na końcu po zakończeniu testu ma wygenerować się raport oraz aplikacja ma zostać zamknięta. Pamięć używana przez Clienta zostaje zwolniona.

 

AfterTest

AfterTest

Kiedy uruchomimy test jako test TestNG zauważymy, że test wykonuje się na urządzeniu, a zrzut przesyłany jest na monitor. Po wszystkim wygenerowany będzie raport oraz statystyki, jak często test failuje, jak często przechodzi i ile razy był uruchamiany. Dodatkowo raport zawiera dla każdej wykonanej przez Clienta akcji zrzut ekranu co się stało po kliknięciu a także w trakcie klikania. Inną zaletą jest zakładka Debug Properties, gdzie znajdują się informacje takie jak clientId, port, dtime, nazwa urządzenia, logLine itd.

W kolejnych artykułach postaram się jeszcze bardziej przybliżyć narzędzie od firmy Experitest, a także pokazać kolejne jego zalety, jak choćby integracja z Jenkinsem czy korzystanie z chmury. Zachęcam do odtworzenia powyższych kroków i spróbowania samodzielnego napisania testu dla dowolnej aplikacji mobilnej, której build posiadacie.

Oceń ten post
Kategorie: Testing
Paulina Łojszczyk
Autor: Paulina Łojszczyk
W Sii pracuję od niemalże 5 lat, moją specjalizacją są testy aplikacji mobilnych. Ponadto zajmuję się także poznawaniem i rozwijaniem testów w narzędziu Tosca. Prywatnie jestem szczęśliwą żoną i mamą rocznej Hani.

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz