Android Samouczek testowania aplikacji z wykorzystaniem frameworka automatyzacji

Czemu Android Testujesz?

Android jest największym systemem operacyjnym na świecie. Jednocześnie, Android jest rozdrobniony: jest mnóstwo urządzeń i Android wersje, z którymi musi być kompatybilna Twoja aplikacja.

Niezależnie od tego, ile czasu zainwestujesz w projekt i wdrożenie, błędy są nieuniknione, a usterki i tak się pojawią.

Android Strategia testowania

Prawidłowy Android strategia testowania powinna obejmować następujące elementy

1. Test jednostkowy
2. Test integracyjny
3. OperaTest narodowy
4. Test systemu

Testy jednostkowe

Testy jednostkowe to zestawy programów zaprojektowane w celu weryfikacji atomowej jednostki kodu źródłowego, na przykład metody lub klasy.

Android platforma jest wstępnie zintegrowana z JUnit Framework 3.0. Jest to framework open source do automatyzacji Testów jednostkowychi umożliwia programistom pisanie efektywnych programów testów jednostkowych.

Uzupełnieniem testów jednostkowych są testy interfejsu użytkownika (UI). Obejmują one komponenty UI aplikacji docelowej i zapewniają, że zwraca ona poprawne dane wyjściowe dla sekwencji działań użytkownika na urządzeniu.

Typowym sposobem przeprowadzania testów interfejsu użytkownika na urządzeniu jest Android Oprzyrządowanie. Ale wiąże się to z problemami z wydajnością. Jedno z najlepszych narzędzi do przeprowadzania testów interfejsu użytkownika Android is Robotium.

⚠️ Uwaga dotycząca wersji: JUnit 3 klasy takie jak Przypadek testowy oprzyrządowania zostały uznane za przestarzałe w API 24; obecne projekty korzystają z AndroidTest X, Espresso i Automatyzatora interfejsu użytkownika. Robotium nie został wydany od 2016 roku.

Testy integracyjne

In Testy integracyjne, wszystkie moduły testowane jednostkowo są łączone i weryfikowane. Android często oznacza to sprawdzenie integracji z komponentami takimi jak Usługa, Aktywność i Testowanie Dostawcy Treści.

Do przeprowadzania testów integracyjnych używa się wielu struktur testowych Android, takich jak Troyd, Robolectric i Robotium.

Operatesty cjonalne

OperaTesty funkcjonalne, zwane także testami akceptacyjnymi lub funkcjonalnymi, to testy wysokiego poziomu, które sprawdzają kompletność i poprawność aplikacji.

In Android, FitNesse jest oprogramowaniem typu open source, które ułatwia przeprowadzanie testów operacyjnych w aplikacjach docelowych.

Testy systemowe

In Testowanie systemu system jest testowany jako całość i sprawdzana jest interakcja pomiędzy komponentami, oprogramowaniem i sprzętem.

In Android, Testowanie systemu zwykle obejmuje

• Testy GUI
• Testy użyteczności
• Testy wydajności
• Testy warunków skrajnych

Na powyższej liście Test wydajności poświęca się więcej uwagi. Możesz użyć narzędzi takich jak Tracopinia do przeprowadzania testów wydajnościowych AndroidTo narzędzie pomoże Ci debugować aplikację i określić jej wydajność. Traceview jest teraz przestarzały na rzecz Profiler procesora.

zautomatyzowane Android Testy

As Android jest rozdrobniony, konieczne jest testowanie na wielu urządzeniach, a to kosztuje. Zautomatyzowane Android Testowanie pomaga obniżyć te koszty.

Korzyści z automatyzacji Android testowanie

• Skróć czas wykonywania przypadków testowych
• Zwiększ produktywność swojego procesu rozwoju
• Wczesne wykrywanie błędów, oszczędność kosztów konserwacji oprogramowania
• Szybko znajdź i napraw błędy podczas wdrażania
• Zadbaj o jakość oprogramowania

Przyjrzymy się następującym dwóm ramom

• Android Ramy testowe
• Ramy testów robotoelektrycznych

Android framework testowy

Jeden ze standardowych frameworków testowych dla Android aplikacje to Android framework testowy. Jest dobrze zintegrowany z Android Narzędzia SDK i ich architektura składają się z trzech części.

1. Pakiet aplikacji to aplikacja docelowa, którą należy przetestować.
2. InstrumentationTestRunner to Przypadek testowy Runner, który wykonuje przypadki testowe w aplikacji docelowej. Zawiera:
   • Narzędzia testowe: Narzędzia SDK do tworzenia testów. Są zintegrowane ze środowiskiem IDE lub uruchamiane z wiersza poleceń.
   • Małpi Biegacz: Narzędzie zapewniające interfejsy API do pisania programów kontrolujących Android urządzenie lub emulator poza Android kod.
3. Pakiet testowy jest zorganizowany w projekty testowe i stosuje konwencję nazewnictwa. Jeśli testowana aplikacja ma nazwę pakietu „com.mydomain.myapp”, to pakiet testowy powinien mieć nazwę „com.mydomain.myapp.test”. Pakiet testowy zawiera 2 obiekty:
   • Klasy przypadków testowych: zawierają metody testowe, które mają zostać wykonane w aplikacji docelowej.
   • Obiekty pozorowane: zawierać dane pozorowane, które będą wykorzystane jako przykładowe dane wejściowe dla przypadków testowych.

Android Klasy przypadków testowych

1. TestCase zawiera JUnit metody biegania JUnit test
2. TestSuite służy do uruchamiania zestawu przypadków testowych
3. InstrumentationTestSuite to pakiet testowy, który wstrzykuje Instrumentation do InstrumentationTestCase przed ich uruchomieniem.
4. InstrumentationTestRunner uruchamia przypadki testowe w aplikacji docelowej.
5. AndroidTestCase rozszerza się JUnit Przypadek testowy z metodami dostępu do zasobów, takich jak kontekst aktywności.
6. ApplicationTestCase weryfikuje klasy aplikacji w kontrolowanym środowisku.
7. InstrumentationTestCase weryfikuje konkretną funkcję lub zachowanie, na przykład dane wyjściowe interfejsu użytkownika aplikacji.
8. ActivityTestCase to klasa bazowa, która obsługuje testowanie działań aplikacji.
9. ProviderTestCase to klasa służąca do testowania pojedynczego ContentProvider.
10. ServiceTestCase testuje klasy usług w środowisku testowym i obsługuje cykl życia usługi.
11. SingleLaunchActivityTestCase służy do testowania pojedynczej aktywności za pomocą InstrumentationTestCase.
12. ActivityUnitTestCase służy do testowania pojedynczej, izolowanej aktywności.
13. Przypadek testowy ActivityInstrumentation2 rozszerza JUnit Klasa TestCase łączy Cię z aplikacją docelową za pomocą instrumentacji, dzięki czemu możesz uzyskać dostęp do komponentów GUI i wysyłać zdarzenia interfejsu użytkownika, takie jak naciśnięcia klawiszy lub dotknięcia.

Poniżej znajduje się przykład ActivityInstrumentationTestCase. Weryfikuje on działanie interfejsu użytkownika aplikacji Kalkulator i sprawdza poprawność wyników interfejsu użytkownika.

Ramy testów Robolectric

Testowanie przy użyciu Android Framework testowy z urządzeniem lub emulatorem jest trudny. Budowanie i uruchamianie testów jest powolne i wymaga dużego nakładu pracy programistycznej. Aby rozwiązać ten problem, istnieje inne rozwiązanie: framework testowy Robolectric.

Robolectric pozwala na bieganie Android testy bezpośrednio na JVM bez potrzeby korzystania z urządzenia lub emulatora.

Zajęcia przypadków testowych Robolectric

Robolectric może wykonywać następujące czynności:

• Zarejestruj się i utwórz klasę Shadow
• Przerwać ładowanie Android klasa
• Używa Javapomóc w zastąpieniu ciał metod Android klasa
• Powiąż obiekt Shadow z Android klasa

Umożliwia to wykonanie testowanego kodu bez Android środowisko.

Inne struktury testowe

Oprócz wyżej wymienionych ram testowych istnieje wiele innych, takich jak:

• Android Raport Junit, niestandardowy moduł uruchamiający testy oprzyrządowania dla Android generujący raporty XML w celu integracji z innymi narzędziami.
• Espresso
• Appium

Mity Android Testy

Wiele przedsiębiorstw rozwija Android Testy strategii opartych na powszechnych błędnych przekonaniach. W tej części przyjrzymy się kilku popularnym mitom i rzeczywistościom na temat Android testowanie.

Mit nr 1: Wszystko Android urządzenia są takie same, więc wystarczy je przetestować na emulatorach

Aplikacja może działać doskonale na emulatorach, jednak ulegać awarii podczas uruchamiania na niektórych rzeczywistych urządzeniach.

Emulatory nie wystarczą do testowania aplikacji mobilnych. Musisz przetestować swoją aplikację na prawdziwych urządzeniach.

Mit nr 2: Wystarczy przetestować na kilku popularnych urządzeniach

Twoja aplikacja wygląda inaczej na różnych urządzeniach, ponieważ sprzęt, rozmiary ekranów i pamięć różnią się. Przetestuj na różnych urządzeniach, wersjach systemu operacyjnego, sieciach operatorów i lokalizacjach.

Mit nr 3: Testowanie eksploracyjne tuż przed uruchomieniem jest wystarczające

• W większości przypadków testowania projektujemy przypadki testowe, a następnie je wykonujemy; w przypadku testowania eksploracyjnego projektowanie i wykonywanie testów odbywają się jednocześnie.
• Nie ma planu ani przygotowania, więc tester uruchamia dowolne testy. Niektóre funkcje są testowane wielokrotnie, podczas gdy inne nie są w ogóle testowane.

Mit nr 4: Jeśli w aplikacji występują jakieś błędy, użytkownicy to zrozumieją

• Jeśli aplikacja nie działa lub zawiera błędy, użytkownicy powinni ją odinstalować.
• Problemy z jakością są pierwszym powodem złych recenzji Google Graj, niszcząc swoją reputację i tracąc zaufanie klientów.

Dlatego tak ważne jest posiadanie odpowiedniego Android wdrożona strategia testowania.

Najlepsze praktyki w Android Testy

• Twórcy aplikacji powinni tworzyć przypadki testowe w tym samym czasie, gdy piszą kod
• Wszystkie przypadki testowe powinny być przechowywane w systemie kontroli wersji wraz z kodem źródłowym
• Korzystaj z ciągłej integracji i uruchamiaj testy za każdym razem, gdy zmieniany jest kod
• Unikaj polegania wyłącznie na emulatorach i zrootowanych urządzeniach; potwierdź wyniki na prawdziwym sprzęcie za pomocą inspektora, takiego jak przeglądarka uiautomatorviewer

FAQ