Testowanie na platformie Android

Projekt Android Open Source (AOSP) udostępnia kilka narzędzi i pakietów testów 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 uruchomić dowolną aplikację innej firmy napisaną przez zewnętrznych deweloperów za pomocą pakietu SDK i NDK Androida. Urządzenia zgodne z Androidem muszą spełniać wymagania określone w dokumentie definicji zgodności (CDD) i przejść pakiet testów zgodności (CTS). Urządzenia zgodne z Androidem mogą korzystać z ekosystemu Androida, w tym potencjalnej licencji na Google Play, potencjalnej licencji na pakiet usług mobilnych Google (GMS) z aplikacją i interfejsami API oraz na korzystanie z znaku towarowego Androida. Każdy może używać kodu źródłowego Androida, ale aby urządzenie było uznawane za część ekosystemu Androida, musi być zgodne z Androidem.
artefakt
Dziennik związany z kompilacją, który umożliwia rozwiązywanie problemów lokalnie.
dokument definicji zgodności (CDD)
Dokument, który zawiera wymagania dotyczące oprogramowania i sprzętu dla urządzenia zgodnego z Androidem.
Zbiór testów zgodności (CTS)

Bezpłatny pakiet testów o jakości komercyjnej, który można pobrać w formie binarnej lub kodu źródłowego w AOSP. CTS to zestaw testów jednostkowych zaprojektowanych tak, aby można je było zintegrować z Twoim codziennym przepływem pracy. Celem testów CTS jest wykrywanie niezgodności i zapewnienie zgodności oprogramowania przez cały proces rozwoju.

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

  • Jeśli test sprawdza poprawność funkcji lub zachowania interfejsu API frameworku i powinien być stosowany przez wszystkich partnerów OEM, powinien być uwzględniony w CTS.
  • Jeśli test ma służyć do wykrywania regresji podczas tworzenia platformy, może wymagać uprawnień uprzywilejowanych i może być zależny od szczegółów implementacji (takich jak te opublikowane w AOSP), powinien być testem platformy.
Usługi mobilne Google (GMS)

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

GoogleTest (GTest)

Platforma testów i mockowania w języku C++. Pliki binarne GTest zwykle uzyskują dostęp do niższych warstw abstrakcji lub wykonują bezpośrednie operacje IPC na różnych usługach systemowych. Podejście do testowania w przypadku GTest jest zwykle ściśle powiązane z testowanym serwisem. CTS zawiera framework GTest.

test z instrumentacją

specjalne środowisko wykonywania testów uruchamiane przez polecenie am instrument, w którym docelowy proces aplikacji jest ponownie uruchamiany i inicjowany z podstawowym kontekstem aplikacji, a w ramach wirtualnej maszyny procesu aplikacji uruchamia się wątek pomiarów. CTS zawiera testy instrumentacji.

Logcat

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

logowanie

prowadzenie dziennika, aby śledzić zdarzenia w systemie komputerowym, takie jak błędy; Rejestrowanie na Androidzie jest skomplikowane ze względu na różnorodność standardów używanych w narzędziu Logcat.

postsubmit test

Test Androida, który jest wykonywany, gdy nowa poprawka zostanie zaakceptowana w głównym gałęzi jądra. Po wpisaniu aosp_kernel jako częściowej nazwy gałęzi możesz wyświetlić listę gałęzi jądra z dostępnymi wynikami. Na przykład wyniki dla android-mainline można znaleźć na stronie https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.

test przed przesłaniem

Test służący do zapobiegania wprowadzania błędów do wspólnych jąder.

Federacja handlowa

Nazwa ta odnosi się do ciągłego testowania, czyli frameworku do przeprowadzania testów na urządzeniach z Androidem. Na przykład Tradefed służy do uruchamiania testów Compatibility Test Suite i Vendor Test Suite.

Zestaw testów dostawcy (VTS)

Zestaw obszernych funkcji do testowania Androida, promowania procesu programowania opartego na testowaniu oraz automatyzacji testów warstwy abstrakcji sprzętowej (HAL) i jądra systemu operacyjnego.

Typy testów platformy

Test platformy zwykle współdziała z co najmniej 1 usługą systemu Android lub warstwą HAL, sprawdza funkcje testowanego obiektu i sprawdza poprawność wyniku testu. Test platformy może:

  • (Typ 1) Wykorzystywanie interfejsów API frameworku za pomocą frameworku Androida. Do interfejsów API, których dotyczy ta funkcja, należą:
    • Publiczne interfejsy API przeznaczone dla aplikacji innych firm
    • Ukryte interfejsy API przeznaczone dla aplikacji uprzywilejowanych, czyli interfejsy API systemowe lub prywatne (@hide, protected, package private)
  • (Typ 2) Wywoływanie usług systemu Androida bezpośrednio za pomocą usługi raw binder lub interfejsu IPC.
  • (Typ 3) Interakcja bezpośrednio z HAL-ami za pomocą interfejsów API niskiego poziomu lub interfejsów IPC.

Testy typu 1 i 2 to zwykle testy instrumentacji, a testy typu 3 to zwykle testy G.

Co dalej?

Oto lista dokumentów, które możesz przeczytać, aby uzyskać więcej informacji: