Testowanie na platformie Android

Projekt Android Open Source (AOSP) udostępnia kilka narzędzi i pakietów testowych do testowania różnych części implementacji. Zanim zaczniesz korzystać ze stron w tej sekcji, zapoznaj się z tymi terminami:

Urządzenie zgodne z Androidem
Urządzenie, na którym można uruchamiać dowolną aplikację innej firmy napisaną przez deweloperów zewnętrznych przy użyciu pakietów SDK i NDK na Androida. Urządzenia zgodne z Androidem muszą spełniać wymagania dokumentu CDD (Compatibility Definition Document) i przejść pakiet testów CTS (Compatibility Test Suite). Urządzenia zgodne z Androidem mogą uczestniczyć w ekosystemie Androida, co obejmuje potencjalne licencjonowanie Google Play, potencjalne licencjonowanie pakietu Usług mobilnych Google (GMS), który zawiera aplikacje i interfejsy API, oraz używanie znaku towarowego Android. Każdy może korzystać z kodu źródłowego Androida, ale aby urządzenie było uznawane za część ekosystemu Androida, musi być z nim zgodne.
artefakt
Log związany z kompilacją, który umożliwia rozwiązywanie problemów lokalnie.
Dokument definicji zgodności (CDD)
Dokument zawierający listę wymagań dotyczących oprogramowania i sprzętu urządzenia zgodnego z Androidem.
Compatibility Test Suite (CTS)

Bezpłatny pakiet testów klasy komercyjnej, który można pobrać jako plik binarny lub jako kod źródłowy w AOSP. CTS to zestaw testów jednostkowych przeznaczonych do integracji z codziennym procesem pracy. Celem pakietu CTS jest wykrywanie niezgodności i zapewnienie, że oprogramowanie pozostanie kompatybilne przez cały proces tworzenia.

Testy CTS i testy platformy nie wykluczają się nawzajem. Oto kilka ogólnych wskazówek:

  • Jeśli test sprawdza poprawność funkcji lub zachowań interfejsu API platformy i ma być egzekwowany u partnerów OEM, powinien znajdować się w CTS.
  • Jeśli test ma na celu wykrywanie regresji podczas tworzenia platformy, może wymagać uprawnień uprzywilejowanych i może zależeć od szczegółów implementacji (zgodnie z wersją AOSP), powinien być testem platformy.
Usługi mobilne Google (GMS)

Zbiór aplikacji i interfejsów API Google, które można wstępnie zainstalować na urządzeniach.

GoogleTest (GTest)

Platforma do testowania i mockowania w C++. Pliki binarne GTest zwykle uzyskują dostęp do warstw abstrakcji niższego poziomu lub wykonują surowe IPC w stosunku do różnych usług systemowych. Podejście do testowania w przypadku GTest jest zwykle ściśle powiązane z testowaną usługą. CTS zawiera platformę GTest.

test z instrumentacją

Specjalne środowisko wykonywania testów uruchamiane przez polecenie am instrument, w którym proces docelowej aplikacji jest ponownie uruchamiany i inicjowany z podstawowym kontekstem aplikacji, a w maszynie wirtualnej procesu aplikacji uruchamiany jest wątek instrumentacji. CTS zawiera testy z instrumentacją.

Logcat

Narzędzie wiersza poleceń, które tworzy dziennik komunikatów systemowych, w tym zrzuty stosu, gdy urządzenie zgłasza błąd, oraz komunikaty zapisane w aplikacji za pomocą klasy Log.

logowanie

Używanie dziennika do śledzenia zdarzeń w systemie komputerowym, takich jak błędy. Logowanie w Androidzie jest złożone ze względu na mieszankę używanych standardów, które są łączone w narzędziu Logcat.

postsubmit test

Test Androida przeprowadzany po zatwierdzeniu nowej poprawki w gałęzi wspólnego jądra. Wpisując aosp_kernel jako część nazwy gałęzi, możesz wyświetlić listę gałęzi jądra, dla których dostępne są wyniki. Na przykład wynikiandroid-mainlinemożna znaleźć na stroniehttps://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.

test przed przesłaniem

Test używany do zapobiegania wprowadzaniu błędów do wspólnych jąder.

Federacja Handlowa

Nazywany też Tradefed, ciągły test framework przeznaczony do przeprowadzania testów na urządzeniach z Androidem. Na przykład Tradefed służy do przeprowadzania testów Compatibility Test Suite i Vendor Test Suite.

Vendor Test Suite (VTS)

Zestaw rozbudowanych funkcji do testowania Androida, promowania procesu programowania opartego na testach i automatyzacji testowania warstwy abstrakcji sprzętu (HAL) i jądra systemu operacyjnego.

Rodzaje testów platformy

Test platformy zwykle wchodzi w interakcję z co najmniej jedną usługą systemową Androida lub warstwą HAL, sprawdza funkcje testowanego obiektu i potwierdza prawidłowość wyniku testu. Test platformy może:

  • (Typ 1) Korzystanie z interfejsów API struktury ćwiczeń za pomocą struktury Androida. Wykorzystywane interfejsy API mogą obejmować:
    • Publiczne interfejsy API przeznaczone dla aplikacji innych firm
    • Ukryte interfejsy API przeznaczone dla aplikacji z uprawnieniami, czyli interfejsy API systemu lub interfejsy API prywatne (@hide lub protected, package private).
  • (Typ 2) Wywołuj usługi systemowe Androida bezpośrednio za pomocą surowych proxy Binder lub IPC.
  • (Typ 3) Bezpośrednia interakcja z HAL-ami za pomocą interfejsów API niskiego poziomu lub interfejsów IPC.

Testy typu 1 i 2 to zwykle testy instrumentacyjne, a testy typu 3 to zazwyczaj testy GTest.

Co dalej?

Szczegółowe informacje znajdziesz w tych dokumentach: