Android Samouczek testowania aplikacji w ramach Automation Framework

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.

Android Testowanie

Nie ma znaczenia, ile czasu zainwestujesz w projekt i wdrożenie, błędy są nieuniknione, a błędy się pojawią.

Android Testowanie

Android Strategia testowania

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

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

Android Strategia testowania

Testy jednostkowe

Testy jednostkowe obejmują zestawy jednego lub większej liczby programów, których celem jest weryfikacja atomowej jednostki kodu źródłowego, np. metody lub klasy.

Android platforma jest wstępnie zintegrowana Junita Ramy 3.0. To platforma open source do automatyzacji Testów jednostkowych. Android Framework testowy to potężne narzędzie dla programistów umożliwiające napisanie efektywnego programu testów jednostkowych.

Integracja Android i JUnit
Integracja Android i JUnit

Dodatkiem do testów jednostkowych są testy interfejsu użytkownika (UI). Testy te dotyczą komponentów interfejsu użytkownika aplikacji docelowej. Testy interfejsu użytkownika zapewniają, że aplikacja zwraca prawidłowe dane wyjściowe interfejsu użytkownika w odpowiedzi na sekwencję działań użytkownika na urządzeniu.

Typowe działania interfejsu użytkownika w aplikacji
Typowe działania interfejsu użytkownika w aplikacji

Powszechnym sposobem przeprowadzania testów wydajności 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 Robot.

Testy integracyjne

In Testy integracyjne, wszystkie moduły testowane jednostkowo, są łączone i weryfikowane. W Android, testy integracyjne często obejmują sprawdzenie integracji zAndroid komponentów, takich jak testowanie usług, testowanie aktywności, testowanie dostawców treści itp

Testy integracyjne
Rodzaje testów integracyjnych Android

Istnieje wiele frameworków testowych używanych do przeprowadzania testów integracyjnych Android takie jak Troyd, Robolectric, Robotium.

Operatesty cjonalne

  • Operanazywane są także Testami Funkcjonalnymi lub Testami Akceptacyjnymi. Są to testy wysokiego poziomu, których zadaniem jest sprawdzenie kompletności i poprawności aplikacji.
  • In Android, FitNesse jest oprogramowaniem typu open source, które ułatwia przeprowadzanie testów operacyjnych dla aplikacji 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 Widok śledzenia przeprowadzić test wydajności Android .To narzędzie może pomóc w debugowaniu aplikacji i profilowaniu jej wydajności.

Automatyczne testowanie Androida

Ponieważ android jest rozdrobniony, konieczne jest testowanie na wielu urządzeniach. Ale to również będzie kosztować pieniądze. Zautomatyzowane Android Testowanie może pomóc w obniżeniu kosztów

Korzyści z automatycznego testowania Androida

  • 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 Aplikacja jest Android framework testowy. Jest to potężny i łatwy w użyciu framework testowy, który jest dobrze zintegrowany z platformą Android Narzędzia SDK.

Android Ramy testowe
Android framework testowy Architektura
  1. Pakiet aplikacji to Twoja docelowa aplikacja, którą należy przetestować
  2. InstrumentationTestRunner jest Przypadek testowy runer, który wykonuje przypadek testowy w aplikacji docelowej. Obejmuje:

2a) Narzędzia testowe: Narzędzia SDK do testów budowania. Są zintegrowane Eclipse IDE lub uruchom jako wiersz poleceń.

2b) Małpi Biegacz: Narzędzie udostępniające interfejsy API umożliwiające pisanie programu sterującego Android urządzenie lub emulator poza Android kod.

  1. Pakiet testowy są zorganizowane w projekty testowe. Ten pakiet jest zgodny z konwencją nazewnictwa. Jeśli testowana aplikacja ma nazwę pakietu „com.mojadomena.myapp”, to pakiet testowy powinien mieć nazwę „com.mojadomena.mojaaplikacja.test”. Pakiet testowy zawiera 2 obiekty jak poniżej:

3a) Klasy przypadków testowych: obejmują metody testowe do wykonania w aplikacji docelowej.

3b) Obiekty próbne: zawiera dane próbne, które zostaną użyte jako przykładowe dane wejściowe w przypadkach testowych.

Android Klasy przypadków testowych

Android Klasy przypadków testowych
AndroidDiagram klas TestCase
  1. Przypadek testowy obejmuje JUnit metody biegania JUnit test
  2. Pakiet testowy służy do uruchamiania zestawu przypadków testowych
  3. Zestaw testów oprzyrządowania to pakiet TestSuite, który wstawia Instrumentację do InstrumentationTestCase przed ich uruchomieniem.
  4. InstrumentationTestRunner to moduł uruchamiający przypadki testowe, który wykonuje przypadek testowy w aplikacji docelowej.
  5. AndroidPrzypadek testowy rozciąga się JUnit Przypadek testowy. Zawiera metody dostępu do zasobów, takie jak kontekst działania.
  6. Przypadek testowy aplikacji weryfikuje klasy aplikacji w kontrolowanym środowisku.
  7. Przypadek testowy oprzyrządowania weryfikuje określoną cechę lub zachowanie aplikacji docelowej, na przykład weryfikuje dane wyjściowe interfejsu użytkownika aplikacji.
  8. Przypadek testowy aktywności to klasa bazowa obsługująca testowanie działań aplikacji.
  9. Przypadek testowy dostawcy to klasa do testowania pojedynczego dostawcy treści.
  10. Przypadek testowy usługi służy do testowania klas usług w środowisku testowym. Wspiera także cykl życia Usługi.
  11. Przypadek testowy SingleLauchActivity służy do testowania pojedynczego działania za pomocą InstrumentationTestCase.
  12. ActivityUnitTestCase służy do testowania pojedynczej izolowanej aktywności.
  13. AktywnośćInstrumentacjaTestCase2 rozszerza JUnit Klasa TestCase. Łączy Cię z aplikacją docelową za pomocą oprzyrządowania. Za pomocą tej klasy można uzyskać dostęp do komponentu GUI aplikacji i wysłać zdarzenie interfejsu użytkownika (naciśnięcie klawisza lub zdarzenie dotknięcia) do interfejsu użytkownika.

Poniżej znajduje się przykład ActivityInstrumentationTestCase. Weryfikuje działanie UI aplikacji Calculator, sprawdza poprawność wyników UI.

Testowanie ActivityInstrumentationTestCase2
Przykład testowania ActivityInstrumentationTestCase2

Ramy testów Robolectric

Testowanie za pomocą Android Testowanie frameworka za pomocą urządzenia lub emulatora jest trudne. Testowanie budowania i uruchamiania jest powolne i wymaga dużego wysiłku programistycznego. Aby rozwiązać ten problem, istnieje inny wybór – Roboelektryczny ramy testowania.

Ramy Robolectric pozwalają na bieganie Android Testy bezpośrednio na JVM bez potrzeba urządzenia lub emulatora.

Zaawansowane funkcje Robolectric
Zaawansowane funkcje Robolectric

Zajęcia przypadków testowych Robolectric

Operafirmy Robolectric
Operafirmy Robolectric
  • Jak pokazano powyżej, Robolectric może wykonywać następujące czynności:
  • Zarejestruj się i utwórz klasę Shadow
  • Przerwać ładowanie Android klasa
  • Używa javaassist do zastąpienia treści metod Android klasa
  • Powiąż obiekt Shadow z Android klasa
  • Dzięki temu testowany kod może zostać wykonany bez Android środowisko.

Inne ramy testowe

Oprócz wspomnianych powyżej frameworków testowych istnieje wiele innych frameworków testowych, takich jak:

Mity Android Testowanie

Wiele przedsiębiorstw rozwija system Android Testowanie 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… wystarczy przetestować na emulatorach

Zacznijmy od prostego przykładu. Aplikacja działa doskonale na emulatorach, ale na niektórych prawdziwych urządzeniach ulega awarii podczas wykonywania

Aplikacja ulega awarii podczas wykonywania na prawdziwym urządzeniu
Aplikacja ulega awarii podczas wykonywania na prawdziwym urządzeniu

Emulatory są niewystarczający do testów mobilnych. Musisz przetestować swoją aplikację na prawdziwych urządzeniach.

Mit nr 2: Wystarczą testy na niektórych popularnych urządzeniach

  • Na różnych urządzeniach Twoja aplikacja wygląda inaczej, ponieważ różne urządzenia mają inny sprzęt, rozmiary ekranu, pamięć itp. Musisz przetestować swoją aplikację na różnych urządzeniach, wersjach systemu operacyjnego, sieciach operatorów i lokalizacjach.

Mit nr 3: Wystarczą testy eksploracyjne tuż przed uruchomieniem

  • Ogólnie rzecz biorąc, we wszystkich testach projektujemy przypadki testowe, a następnie je wykonujemy. Jednak w przypadku testów eksploracyjnych, projektowania i wykonywania testów wszystko będzie wykonywane razem.
  • W testach eksploracyjnych nie ma planu i przygotowania, wtedy tester robi takie testy, jakie chce. Niektóre funkcje będą testowane wielokrotnie, a niektóre w ogóle nie będą testowane.

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

  • Jeśli aplikacja nie działa i zawiera błędy, użytkownicy odinstalowują Twoją aplikację
  • Problemy z jakością są pierwszą przyczyną złej recenzji w Google Play. Wpływa to na Twoją reputację i tracisz zaufanie klientów.

Dlatego też tak ważne jest posiadanie odpowiedniej strategii testowania systemu Android

Najlepsze praktyki w Android Testowanie

  • Twórcy aplikacji powinni tworzyć przypadki testowe w tym samym czasie, gdy piszą kod
  • Wszystkie przypadki testowe powinny być przechowywane w kontroli wersji – razem z kodem źródłowym
  • Korzystaj z ciągłej integracji i uruchamiaj testy za każdym razem, gdy zmieniany jest kod
  • Unikaj używania emulatorów i urządzeń zrootowanych