Rozpocznij testowanie za pomocą interfejsu wiersza polecenia gcloud

W tym przewodniku opisano, jak uruchomić test instrumentacji, Robo lub Game Loop za pomocą interfejsu wiersza polecenia gcloud .

Pełną listę poleceń gcloud , których możesz używać w aplikacji na Androida w Test Lab, znajdziesz w dokumentacji referencyjnej gcloud firebase test android .

Zanim zaczniesz

Jeśli jeszcze tego nie zrobiłeś, dodaj Firebase do swojego projektu na Androida .

Krok 1. Skonfiguruj interfejs wiersza polecenia gcloud

1. Pobierz pakiet Google Cloud SDK.

Obejmuje to narzędzie Gcloud CLI.

2. Upewnij się, że Twoja instalacja jest aktualna:

   gcloud components update
   

3. Zaloguj się do gcloud CLI, używając swojego konta Google:

   gcloud auth login
   

4. Ustaw projekt Firebase w gcloud, gdzie PROJECT_ID to identyfikator projektu Firebase:

   gcloud config set project PROJECT_ID
   

Krok 2. Sprawdź dostępne urządzenia testowe

Użyj poniższych poleceń gcloud, aby wyświetlić urządzenia testowe i języki, które są dostępne dla Twojego testu.

Opcjonalnie możesz również pobrać przykładową aplikację Notatnik , aby od razu rozpocząć uruchamianie poleceń. Użyj pliku binarnego app-debug-unaligned.apk i pliku testów oprzyrządowania app-debug-test-unaligned.apk , które znajdują się w NotePad/app/build/outputs/apk/ .

• models list : uzyskaj aktualną listę dostępnych urządzeń z systemem Android do testowania.

  gcloud firebase test android models list
  

  W wyniku polecenia:

  • Kolumna MODEL_ID zawiera identyfikator, którego można później użyć do uruchomienia testów na modelu urządzenia.
  • Kolumna OS_VERSION_ID zawiera wersje systemu operacyjnego obsługiwane przez urządzenie.

  Przykładowe wyjście

  

• models describe : Uzyskaj więcej informacji o określonym MODEL_ID Android .

  gcloud firebase test android models describe MODEL_ID
  

  Dane wyjściowe zawierają markę modelu urządzenia, producenta, wersje systemu operacyjnego, obsługiwane poziomy interfejsu API, obsługiwane interfejsy binarne aplikacji (ABI), daty wydania oraz czy urządzenie jest fizyczne czy wirtualne.

• versions list : pobierz listę aktualnie dostępnych wersji systemu operacyjnego do przetestowania.

  gcloud firebase test android versions list
  

  Możesz użyć identyfikatora z jednej z pierwszych dwóch kolumn danych wyjściowych polecenia ( OS_VERSION_ID i VERSION ), aby później uruchomić testy dla wersji systemu operacyjnego Android. Jeśli nie określisz wersji systemu operacyjnego Android do testowania, zostanie użyta wartość domyślna zaznaczona w kolumnie TAGS .

  Przykładowe wyjście

  

• locales list : Pobierz aktualną listę dostępnych ustawień regionalnych do testowania.

  gcloud firebase test android versions list
  

  Pierwsza kolumna danych wyjściowych polecenia, LOCALE , zawiera identyfikator, którego można później użyć do uruchomienia testów względem ustawień regionalnych. Jeśli nie określisz ustawień regionalnych do testowania, angielski jest używany jako domyślne ustawienia regionalne.

Uruchamianie testów

Teraz, gdy znasz już zakres modeli urządzeń, ustawień regionalnych i wersji systemu operacyjnego dostępnych do testowania Twojej aplikacji, możesz określić urządzenia za pomocą polecenia gcloud firebase test android run i flagi --device , aby uruchomić testy Robo lub oprzyrządowanie.

Uwaga: flaga --device jest teraz preferowanym sposobem określania urządzeń testowych i nie może być używana w połączeniu z --devices-ids , --os-version-ids , --locales ani --orientations . Aby dowiedzieć się więcej o tych starszych flagach, zobacz listę wycofanych flag wymiarów urządzenia w gcloud firebase test android run .

Uruchamianie testu Robo

Nawet jeśli nie masz żadnych testów oprzyrządowania, nadal możesz szukać błędów w swojej aplikacji. Użyj testu Robo, aby automatycznie sprawdzić interfejs użytkownika aplikacji. Test Robo sprawdza aplikację, wykonując statyczną analizę różnych ścieżek za pośrednictwem interfejsu użytkownika aplikacji, a następnie indeksując aplikację, aby znaleźć awarie i inne potencjalne problemy.

Zacznijmy od uruchomienia przykładowego polecenia:

gcloud firebase test android run \
  --type robo \
  --app app-debug-unaligned.apk \
  --device model=Nexus6,version=21,locale=en,orientation=portrait  \
  --device model=Nexus7,version=19,locale=fr,orientation=landscape \
  --timeout 90s

Parametr --type robo jest niejawny, jeśli nie określono wartości --type . Aby wyświetlić pełny zestaw opcji wiersza poleceń do uruchamiania testów, wpisz: gcloud help firebase test android run . Jako alternatywę do określania wszystkich tych argumentów w wierszu poleceń, możesz opcjonalnie określić swoje argumenty w pliku argumentów w formacie YAML. Uruchom gcloud topic arg-files aby dowiedzieć się, jak korzystać z tej funkcji.

Zobacz sekcję Analiza wyników testu , aby dowiedzieć się, jak zbadać wyniki testu z testu Robo.

Przeprowadzanie testów oprzyrządowania

Teraz użyj narzędzia wiersza poleceń gcloud , aby uruchomić testy Espresso aplikacji Notatnik na określonych konfiguracjach urządzenia z Androidem. Użyj typu testu instrumentation , aby uruchomić testy w app-debug-test-unaligned.apk w następujący sposób:

gcloud firebase test android run \
  --type instrumentation \
  --app app-debug-unaligned.apk \
  --test app-debug-test-unaligned.apk \
  --device model=Nexus6,version=21,locale=en,orientation=portrait  \
  --device model=Nexus7,version=19,locale=fr,orientation=landscape

Parametr --type instrumentation jest niejawny, jeśli testowy pakiet APK został określony z --test . Jako alternatywę do określania wszystkich tych argumentów w wierszu poleceń, możesz opcjonalnie określić swoje argumenty w pliku argumentów w formacie YAML. Uruchom gcloud topic arg-files aby dowiedzieć się, jak korzystać z tej funkcji.

Gcloud CLI obsługuje Android Test Orchestrator . Program Orchestrator wymaga AndroidJUnitRunner w wersji 1.1 lub nowszej. Aby ją włączyć, użyj gcloud firebase test android run z
--use-orchestrator . Aby go wyłączyć, użyj flagi --no-use-orchestrator .

Uwaga: Aby uniknąć wydawania limitu lub naliczania opłat za nieprawidłowe testy, uruchom program Orchestrator lokalnie przed wypróbowaniem go w laboratorium testowym. Upewnij się, że program Orchestrator działa w Twojej aplikacji, uruchamiając test na własnym komputerze przed przesłaniem pakietu APK. Należy pamiętać, że testowanie za pomocą programu Orchestrator trwa nieco dłużej niż zwykle i może wpłynąć na rozliczenia lub spowodować, że testy przekroczą limit czasu.

Możesz także kontrolować sposób, w jaki Test Lab uruchamia testy oprzyrządowania, używając dodatkowych flag, które nie są pokazane powyżej. Na przykład możesz użyć flagi --test-targets , aby przetestować pojedynczą klasę lub metodę klasy używaną przez testowy pakiet APK. Możesz również dowiedzieć się, czy test, który się nie powiódł, był faktycznie niestabilny, czy nie, używając --num-flaky-test-attempts , która określa liczbę ponownych prób wykonania testu, jeśli co najmniej jeden z jego przypadków testowych zawieść z jakiegokolwiek powodu. Więcej informacji znajdziesz w artykule testowanie gcloud Firebase na Androida .

Raporty pokrycia kodu dla testów oprzyrządowania

Test Lab obsługuje narzędzia do raportowania pokrycia kodu EMMA i JaCoCo . Jeśli masz jakieś narzędzie zintegrowane z kompilacją swojej aplikacji, możesz uzyskać raport pokrycia kodu dla testów w laboratorium testowym, uruchamiając gcloud firebase test android run z dodatkowymi argumentami. Jeśli Android Test Orchestrator nie jest włączony, użyj następującego:

gcloud firebase test android run \
  --type instrumentation \
  --app your-app.apk \
  --test your-app-test.apk \
  --device model=TestDevice,version=AndroidVersion  \
  --environment-variables coverage=true,coverageFile="/sdcard/Download/coverage.ec" \
  --directories-to-pull /sdcard/Download

Jeśli generujesz raporty pokrycia kodu, używając jednocześnie narzędzia Android Test Orchestrator, zmodyfikuj zmienne środowiskowe w następujący sposób:

gcloud firebase test android run \
  --type instrumentation \
  --app your-app.apk \
  --test your-app-test.apk \
  --device model=TestDevice,version=AndroidVersion  \
  --environment-variables clearPackageData=true,coverage=true,coverageFilePath="/sdcard/Download/" \
  --directories-to-pull /sdcard/Download

Gdy Test Lab zakończy przeprowadzanie testów, znajdź swoje raporty dotyczące pokrycia kodu w Google Cloud Storage:

1. Otwórz link konsoli Firebase, który narzędzie gcloud wydrukowało nad tabelą wyników testu w terminalu.
2. Kliknij wykonanie testu z listy znajdującej się pod tym linkiem, aby otworzyć stronę szczegółów tego wykonania.
3. Kliknij Wyniki testu , aby przejść do zasobnika Cloud Storage z wynikami testu wykonania.
4. Otwórz artifacts/coverage.ec aby zobaczyć raport dotyczący pokrycia kodu.

Uwaga: pobranie katalogu sdcard/Download dla każdego testu powoduje umieszczenie wszystkich plików z tego katalogu w zasobniku Cloud Storage testu. Jeśli korzystasz z planu płatności Blaze, a Twoja aplikacja tworzy wiele plików w tym katalogu, pobranie katalogu może spowodować naliczenie dodatkowych opłat za przechowywanie.

Przeanalizuj wyniki swoich testów

Po kilku minutach narzędzie gcloud drukuje podstawowe podsumowanie wyników testu:

Dane wyjściowe testu z wiersza poleceń zawierają również łącze do przeglądania wyników testu. Aby dowiedzieć się więcej o tym, jak interpretować te wyniki, zobacz Analizowanie laboratorium Firebase pod kątem wyników na Androida .

Niestandardowe logowanie i wprowadzanie tekstu za pomocą testu Robo

Robo test automatycznie wypełnia ekrany logowania, które używają konta Google do uwierzytelniania, chyba że użyjesz parametru --no-auto-google-login . Może również wypełniać niestandardowe ekrany logowania przy użyciu podanych przez Ciebie danych logowania do konta testowego. Możesz również użyć tego parametru, aby podać niestandardowy tekst wejściowy dla innych pól tekstowych używanych przez Twoją aplikację.

Aby uzupełnić pola tekstowe w aplikacji, użyj parametru --robo-directives i podaj listę par key-value rozdzielonych przecinkami, gdzie key jest nazwą zasobu Androida docelowego elementu interfejsu użytkownika, a value jest ciąg tekstowy . Możesz również użyć tej flagi, aby powiedzieć Robo, aby ignorował określone elementy interfejsu użytkownika (np. przycisk „wyloguj”). Pola EditText są obsługiwane, ale nie pola tekstowe w elementach interfejsu WebView .

Na przykład możesz użyć następującego parametru do niestandardowego logowania:

--robo-directives username_resource=username,password_resource=password

Uwaga: używaj danych logowania tylko dla kont testowych, które nie są powiązane z prawdziwymi użytkownikami.

Dostępne komendy i flagi

Interfejs wiersza polecenia gcloud w laboratorium testowym zawiera kilka poleceń i flag, które umożliwiają uruchamianie testów o różnych specyfikacjach:

• Flaga Android Test Orchestrator : flaga umożliwiająca włączenie narzędzia Orchestrator, które umożliwia uruchamianie każdego z testów aplikacji we własnym wywołaniu Instrumentation . Laboratorium testowe zawsze uruchamia najnowszą wersję programu Orchestrator.

• Flagi testowe pętli gry : zestaw flag konfiguracyjnych, które włączają i kontrolują „tryb demonstracyjny”, aby symulować działania graczy w aplikacjach gier. Dowiedz się więcej o uruchamianiu testów Game Loop za pomocą Test Lab .

• Flaga jednolitego fragmentowania (w wersji beta) : flaga określająca liczbę fragmentów, do których chcesz równomiernie dystrybuować przypadki testowe. Fragmenty są uruchamiane równolegle na osobnych urządzeniach.

• Flaga ręcznego fragmentowania (w wersji beta) : flaga określająca grupę pakietów, klas i/lub przypadków testowych do uruchomienia we fragmencie (grupie przypadków testowych). Fragmenty są uruchamiane równolegle na osobnych urządzeniach.

• Flaga profili ruchu sieciowego (w wersji beta) : flaga określająca profil sieci używany w testach z urządzeniami fizycznymi. Profile sieciowe emulują różne warunki sieciowe, umożliwiając testowanie wydajności aplikacji w niepewnych lub nieprzewidywalnych sieciach.

Skryptowanie poleceń gcloud za pomocą Test Lab

Za pomocą skryptów powłoki lub plików wsadowych możesz zautomatyzować polecenia testowania aplikacji mobilnych, które w innym przypadku byłyby uruchamiane za pomocą wiersza poleceń gcloud. Poniższy przykładowy skrypt bash uruchamia test instrumentacji z dwuminutowym limitem czasu i zgłasza, czy przebieg testu zakończył się pomyślnie:

if gcloud firebase test android run --app my-app.apk --test my-test.apk --timeout 2m
then
    echo "Test matrix successfully finished"
else
    echo "Test matrix exited abnormally with non-zero exit code: " $?
fi

Kody wyjścia skryptu

Laboratorium testowe udostępnia kilka kodów wyjścia, których można użyć, aby lepiej zrozumieć wyniki testów uruchamianych za pomocą skryptów lub plików wsadowych.

Skryptowanie kodów wyjścia dla laboratorium testowego

Kod wyjścia	Uwagi
0	Wszystkie wykonania testów zaliczone.
1	Wystąpiła ogólna awaria. Możliwe przyczyny to: nieistniejąca nazwa pliku lub błąd HTTP/sieci.
2	Testowanie zostało zakończone, ponieważ podano nieznane polecenia lub argumenty.
10	Co najmniej jeden przypadek testowy (testowane klasy lub metody klas) w ramach wykonywania testu nie przeszedł pomyślnie.
15	Laboratorium Firebase Test Lab nie mogło określić, czy macierz testów zakończyła się powodzeniem, czy nie, z powodu nieoczekiwanego błędu.
18	Środowisko testowe dla tego wykonania testu nie jest obsługiwane z powodu niezgodnych wymiarów testowych. Ten błąd może wystąpić, jeśli wybrany poziom interfejsu API systemu Android nie jest obsługiwany przez wybrany typ urządzenia.
19	Macierz testowa została anulowana przez użytkownika.
20	Wystąpił błąd infrastruktury testowej.