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 deweloperów zewnętrznych za pomocą pakietu Android SDK i NDK. Urządzenia zgodne z Androidem muszą spełniać wymagania dokumentu definicji zgodności (CDD) i przejść testy Compatibility Test Suite (CTS). Urządzenia zgodne z Androidem mogą uczestniczyć w ekosystemie Androida, co obejmuje potencjalną licencję na Google Play, potencjalną licencję na pakiet aplikacji i interfejsów API Usług mobilnych Google (GMS) oraz możliwość używania 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ć zgodne z Androidem.
- Artefakt
- Log związany z kompilacją, który umożliwia lokalne rozwiązywanie problemów.
- Dokument definicji zgodności (CDD)
- Dokument, który zawiera wymagania dotyczące oprogramowania i sprzętu urządzenia zgodnego z Androidem.
- Compatibility Test Suite (CTS)
Bezpłatny zestaw testów klasy komercyjnej, który można pobrać jako plik binarny lub kod źródłowy w AOSP. CTS to zestaw testów jednostkowych, które można zintegrować z codziennym przepływem pracy. Celem CTS jest wykrywanie niezgodności i zapewnienie, że oprogramowanie pozostanie zgodne przez cały proces tworzenia.
Testy CTS i testy platformy nie wykluczają się wzajemnie. Oto kilka ogólnych wytycznych:
- Jeśli test sprawdza poprawność funkcji lub zachowań interfejsu API platformy i powinien być egzekwowany u partnerów OEM, powinien znajdować się w CTS.
- Jeśli test ma na celu wykrywanie regresji podczas tworzenia platformy i może wymagać uprawnień uprzywilejowanych oraz może zależeć od szczegółów implementacji (udostępnionych w 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 tworzenia atrap w języku 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 GTest jest zwykle ściśle powiązane z testowaną usługą. CTS zawiera platformę GTest.
- Test z instrumentacją
Specjalne środowisko wykonywania testów uruchamiane za pomocą polecenia
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 log wiadomości systemowych, w tym ślady stosu, gdy urządzenie zgłasza błąd, oraz wiadomości zapisane w aplikacji za pomocą klasy
Log.- Logowanie
Używanie logu do śledzenia zdarzeń systemu komputerowego, takich jak błędy. Logowanie w Androidzie jest złożone ze względu na połączenie standardów używanych w narzędziu Logcat.
- Test po przesłaniu
Test Androida, który jest wykonywany, gdy nowa poprawka zostanie zatwierdzona w wspólnym gałęzi jądra. Wpisując
aosp_kerneljako częściową nazwę gałęzi, możesz wyświetlić listę gałęzi jądra z dostępnymi wynikami. Na przykład wyniki dlaandroid-mainlinemożna znaleźć na stronie https://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.
- Trade Federation
Nazywana też Tradefed, platforma do ciągłego testowania przeznaczona do uruchamiania 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.
- Vendor Test Suite (VTS)
Zestaw rozbudowanych funkcji do testowania Androida, promowania procesu tworzenia opartego na testach i automatyzowania testowania warstwy abstrakcji sprzętu (HAL) oraz jądra systemu operacyjnego.
Typy testów platformy
Test platformy zwykle wchodzi w interakcję z co najmniej jedną usługą systemową Androida lub warstwą HAL, wykorzystuje funkcje testowanego obiektu i sprawdza poprawność wyniku testu. Test platformy może:
- (Typ 1) Wykorzystywać interfejsy API platformy za pomocą platformy Android. Wykorzystywane interfejsy API mogą obejmować:
- Publiczne interfejsy API przeznaczone dla aplikacji innych firm.
- Ukryte interfejsy API przeznaczone dla aplikacji uprzywilejowanych, czyli interfejsy API systemu lub interfejsy API prywatne (
@hide,protected,package private).
- (Typ 2) Wywoływać usługi systemowe Androida bezpośrednio za pomocą surowych proxy binder lub IPC.
- (Typ 3) Bezpośrednio wchodzić w interakcję z HAL za pomocą interfejsów API niskiego poziomu lub interfejsów IPC.
Testy typu 1 i 2 to zwykle testy z instrumentacją, a testy typu 3 to zwykle testy GTest.
Co dalej?
Oto lista dokumentów, które możesz przeczytać, aby uzyskać więcej informacji:
Jeśli nie znasz architektury Androida, przeczytaj artykuł Omówienie architektury.
Jeśli tworzysz urządzenie zgodne z Androidem, przeczytaj artykuł Omówienie programu zgodności z Androidem.
Aby zintegrować testy instrumentacji, funkcjonalne, metryk i hosta JAR z usługą ciągłego testowania platformy, przeczytaj artykuł Przepływ pracy podczas tworzenia testów.
Aby wykrywać luki w zabezpieczeniach i zabezpieczać przed nimi urządzenia, przeczytaj artykuł Testowanie zabezpieczeń.
Aby dowiedzieć się więcej o testowaniu implementacji HAL i jądra, przeczytaj artykuł Vendor Test Suite (VTS) i infrastruktura.
Aby dowiedzieć się więcej o testowaniu aplikacji, przeczytaj artykuł Podstawy testowania aplikacji na Androida i wykonaj ćwiczenia z artykułu Zaawansowany Android w środowisku Kotlin 05.1:podstawy testowania , korzystając z podanych przykładów.
Dowiedz się więcej o podstawowych testach przed przesłaniem, które są dostępne dzięki hookom repo. Te hooki można używać do uruchamiania narzędzi do sprawdzania kodu, sprawdzania formatowania i wywoływania testów jednostkowych przed wykonaniem dalszych czynności, takich jak przesłanie zatwierdzenia. Te hooki są domyślnie wyłączone. Więcej informacji znajdziesz w artykule o hookach przed przesłaniem w AOSP.
Aby dowiedzieć się więcej o logowaniu, przeczytaj artykuł Omówienie logowania.
Aby dowiedzieć się, jak debugować kod Androida, przeczytaj artykuł Debugowanie natywnego kodu platformy Android.