Rozpocznij testowanie za pomocą interfejsu wiersza polecenia gcloud

Firebase Test Lab zapewnia infrastrukturę opartą na chmurze do testowania aplikacji na Androida, w tym pełną integrację z interfejsem wiersza poleceń (CLI) gcloud. Ten dokument obejmuje instalację i konfigurację wymaganą do rozpoczęcia korzystania z Test Lab z interfejsu wiersza polecenia gcloud.

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

Jeśli nie masz projektu Firebase dla swojej aplikacji, przejdź do konsoli Firebase i kliknij Utwórz nowy projekt, aby utworzyć go teraz. Będziesz potrzebować prawa własności lub uprawnień do edycji w swoim projekcie.

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 interfejsu wiersza polecenia gcloud, używając swojego konta Google:

   gcloud auth login
   

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

   gcloud config set project PROJECT_ID
   

Skonfiguruj swój test

W tym przykładzie przeprowadzisz kilka testów na prostej aplikacji na Androida do robienia notatek o nazwie Notatnik.

1. Pobierz binarny plik APK dla aplikacji Notepad ( app-debug-unaligned.apk ) i odpowiadające mu testy oprzyrządowania ( app-debug-test-unaligned.apk ) udostępniony w katalogu NotePad / app / build / output / apk / notatnika .zip .

2. Pobierz aktualną listę urządzeń z Androidem, z którymi można przetestować, w następujący sposób:

   
   $ gcloud firebase test android models list
   

   Pierwsza kolumna danych wyjściowych polecenia, MODEL_ID , zawiera identyfikator, którego można później użyć do uruchomienia testów na określonym modelu. Kolumna OS_VERSION_ID zawiera listę wersji systemu operacyjnego obsługiwanych przez to urządzenie. Jeśli nie określisz MODEL_ID do testowania, używana jest wartość domyślna zanotowana w kolumnie TAGS .

3. Dowiedz się więcej o konkretnym MODEL_ID Android MODEL_ID pomocą polecenia MODEL_ID firebase test android models describe , w następujący sposób:

   
   $ gcloud firebase test android models describe Nexus5
   

   Przykładowe polecenie pokazane powyżej zawiera szczegółowe informacje o modelu Nexus5 , w tym o marce, producencie i obsługiwanych poziomach API oraz o tym, czy model jest fizyczny lub wirtualny.

4. Pobierz aktualną listę wersji systemu operacyjnego Android, które można przetestować pod kątem:

   
   $ 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, używana jest wartość domyślna zanotowana w kolumnie TAGS .

5. Pobierz aktualną listę ustawień narodowych, dla których można przetestować:

   
   $ gcloud firebase test android locales list
   

   Pierwsza kolumna danych wyjściowych polecenia, LOCALE , zawiera identyfikator, którego można później użyć do uruchomienia testów w odniesieniu do ustawień narodowych. Jeśli nie określisz ustawień narodowych do testowania, domyślnym ustawieniem narodowym jest język angielski. Dane wyjściowe polecenia nie są tutaj wyświetlane, ponieważ dostępne są setki ustawień regionalnych.

Przeprowadzanie testów

Teraz, gdy znasz już zakres modeli urządzeń, wersje systemu operacyjnego i ustawienia regionalne dostępne do użycia podczas testowania aplikacji, możesz użyć tych informacji do określenia urządzeń testowych za pomocą polecenia gcloud firebase test android run i flagi --device . To polecenie i flaga są używane niezależnie od tego, czy używasz testu Robo do automatycznego testowania aplikacji, czy też uruchamiasz testy oprzyrządowania napisane specjalnie do testowania aplikacji.

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, zapoznaj się z listą wycofanych flag wymiarów urządzeń w witrynie 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 zautomatyzować przegląd interfejsu użytkownika aplikacji. Test Robo sprawdza aplikację, wykonując statyczną analizę różnych ścieżek w interfejsie użytkownika aplikacji, a następnie przeszukując aplikację, aby znaleźć awarie i inne potencjalne problemy.

Zacznijmy od wykonania 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 . Możesz zobaczyć pełny zestaw opcji wiersza poleceń do uruchamiania testów, wpisując: gcloud help firebase test android run . Alternatywą dla określenia wszystkich tych argumentów w wierszu poleceń jest opcjonalne określenie argumentów w pliku argumentów w formacie YAML. Uruchom polecenie 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 Robo.

Przeprowadzanie testów oprzyrządowania

Teraz użyj narzędzia wiersza poleceń gcloud , aby uruchomić testy Espresso aplikacji Notepad na określonych konfiguracjach urządzeń z systemem Android, używając typu testu instrumentation do uruchomienia testów 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 plik APK został określony za pomocą --test . Alternatywą dla określenia wszystkich tych argumentów w wierszu poleceń jest opcjonalne określenie argumentów w pliku argumentów w formacie YAML. Uruchom polecenie gcloud topic arg-files aby dowiedzieć się, jak korzystać z tej funkcji.

Interfejs wiersza polecenia gcloud obsługuje aplikację Android Test Orchestrator . Orchestrator wymaga systemu AndroidJUnitRunner w wersji 1.0 lub nowszej. Aby ją włączyć, użyj narzędzia gcloud firebase test android run z
--use-orchestrator . Aby go wyłączyć, użyj flagi --no-use-orchestrator .

Uwaga: Możesz także kontrolować sposób, w jaki Test Lab przeprowadza testy oprzyrządowania, używając dodatkowych flag, które nie są pokazane powyżej. Możesz na przykład użyć flagi --test-targets aby przetestować pojedynczą klasę lub metodę klasy używaną przez testowy plik APK. Możesz również dowiedzieć się, czy test, który się nie powiódł, był faktycznie niestabilny, czy nie, używając flagi `` --num-flaky-test-samples '', która określa, ile razy należy powtórzyć wykonanie testu, jeśli jeden lub więcej z jego przypadki testowe kończą się niepowodzeniem z jakiegokolwiek powodu. Aby dowiedzieć się więcej, zobacz temat Test 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 jedno narzędzie zintegrowane z kompilacją aplikacji, możesz uzyskać raport pokrycia kodu dla testów w laboratorium gcloud firebase test android run polecenie gcloud firebase test android run z następującymi argumentami:

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/coverage.ec" \
  --directories-to-pull /sdcard

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

1. Otwórz link do konsoli gcloud wydrukowany przez narzędzie gcloud nad tabelą wyników testu w terminalu.
2. Kliknij wykonanie testu z listy pod tym łączem, aby otworzyć stronę szczegółów tego wykonania.
3. Kliknij Wyniki testu, aby przejść do zasobnika Cloud Storage z wynikami testów tego wykonania.
4. Otwórz artifacts/coverage.ec aby wyświetlić raport o pokryciu kodu.

Uwaga: sdcard katalogu sdcard dla każdego testu powoduje umieszczenie wszystkich plików z tego katalogu w zasobniku Cloud Storage testu. Jeśli korzystasz z abonamentu Blaze, a Twoja aplikacja tworzy wiele plików w tym katalogu, pobranie katalogu może spowodować znaczne wydatki na przechowywanie.

Przeanalizuj wyniki testu

Po kilku minutach podstawowe podsumowanie wyników testu zostanie wydrukowane przez narzędzie gcloud:

Dane wyjściowe przebiegu testu w wierszu poleceń zawierają również łącze do wyświetlenia wyników testu. Aby dowiedzieć się więcej o tym, jak interpretować te wyniki, zobacz Analizowanie wyników z Laboratorium Firebase dla Androida .

Niestandardowe logowanie i wprowadzanie tekstu za pomocą testu Robo

Test Robo automatycznie wypełnia ekrany logowania, które używają konta Google do uwierzytelniania, chyba że używasz parametru --no-auto-google-login . Może również wypełniać niestandardowe ekrany logowania, korzystając z 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 aplikację.

Aby wypełnić pola tekstowe w aplikacji, użyj parametru --robo-directives i podaj listę par key-value oddzielonych przecinkami, gdzie key jest nazwą zasobu Androida docelowego elementu interfejsu użytkownika, a value jest ciąg tekstowy . Możesz także użyć tej flagi, aby nakazać Robo ignorowanie określonych elementów interfejsu użytkownika (np. Przycisku „wyloguj”). Pola EditText są obsługiwane, ale nie pola tekstowe w elementach interfejsu użytkownika WebView .

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

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

Przestroga: poświadczeń należy używać tylko dla kont testowych, które nie są powiązane z rzeczywistymi użytkownikami.

Dostępne polecenia i flagi

Interfejs wiersza polecenia narzędzia Test Lab gcloud ma kilka dostępnych poleceń i flag, które umożliwiają uruchamianie testów z różnymi specyfikacjami:

• Flaga Android Test Orchestrator : flaga włączająca Orchestrator, narzędzie, które umożliwia uruchamianie każdego testu aplikacji w jego własnym wywołaniu Instrumentation . Test Lab zawsze uruchamia najnowszą wersję programu Orchestrator.

• Flagi testowe pętli gry : zestaw flag konfiguracyjnych, które włączają i kontrolują „tryb demonstracyjny” w celu symulowania działań gracza w aplikacjach do gier. Dowiedz się więcej o przeprowadzaniu testów pętli gier za pomocą Test Lab .

• Flaga Uniform Sharding (w wersji beta) : flaga określająca liczbę fragmentów, na które chcesz równomiernie rozdzielić przypadki testowe. Fragmenty są uruchamiane równolegle na oddzielnych urządzeniach.

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

• Flaga profili ruchu sieciowego (w wersji beta) : flaga określająca, którego profilu sieciowego używają testy z urządzeniami fizycznymi. Profile sieciowe emulują różne warunki sieciowe, umożliwiając przetestowanie wydajności aplikacji w zawodnych lub nieprzewidywalnych sieciach.

Uwaga: uruchom program Orchestrator lokalnie przed wypróbowaniem go w laboratorium testowym. Aby uniknąć wydawania limitu na nieprawidłowe testy lub naliczania opłat za nieprawidłowe testy, upewnij się, że Orchestrator działa w Twojej aplikacji, uruchamiając test na swoim komputerze przed przesłaniem pakietu APK. Ponadto testowanie w programie Orchestartor trwa nieco dłużej niż zwykle i może wpłynąć na Twój limit lub rozliczenia.

Tworzenie skryptów poleceń gcloud za pomocą Test Lab

Możesz użyć skryptów powłoki lub plików wsadowych, aby 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 oprzyrządowania z dwuminutowym przekroczeniem limitu czasu i informuje, czy uruchomienie testowe zakończyło 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 skryptów

Test Lab udostępnia kilka kodów zakończenia, których można użyć do lepszego zrozumienia wyników testów wykonywanych za pomocą skryptów lub plików wsadowych.

Skrypty kodu wyjścia dla laboratorium testowego

Kod zakończenia	Uwagi
0	Wszystkie testy przeszły pomyślnie.
1	Wystąpiła ogólna awaria. Możliwe przyczyny to: nieistniejąca nazwa pliku lub błąd HTTP / sieciowy.
2	Testowanie zakończyło się, ponieważ podano nieznane polecenia lub argumenty.
10	Co najmniej jeden przypadek testowy (testowane klasy lub metody klas) w ramach wykonania testu nie przeszedł pomyślnie.
15	Laboratorium Firebase nie mogło określić, czy macierz testów przeszła pomyślnie, czy nie powiodła się z powodu nieoczekiwanego błędu.
18	Środowisko testowe dla tego wykonania testu nie jest obsługiwane z powodu niezgodnych wymiarów testu. 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	Matryca testowa została anulowana przez użytkownika.
20	Wystąpił błąd infrastruktury testowej.