Android Open Source Project (AOSP) udostępnia kilka narzędzi i pakietów testowych do testowania różnych elementów implementacji. Przed użyciem stron w tej zapoznaj się z tymi terminami:
- Urządzenie zgodne z Androidem
- Urządzenie, na którym można uruchomić dowolną aplikację innej firmy napisaną przez dewelopera za pomocą pakietu SDK na Androida i pakietu NDK. Urządzenia zgodne z Androidem muszą spełniać wymagania wymagania programu Dokument definicji zgodności (CDD) i przekazać Compatibility Test Suite (CTS). Zgodność z Androidem urządzeń mogą uczestniczyć w ekosystemie Androida, który obejmuje m.in. potencjalna licencja na Google Play, potencjalna licencja pakietu Usług mobilnych Google (GMS), aplikacji i interfejsów API oraz użycia znaku towarowego Android. Każdy jest mile widziany wykorzystują kod źródłowy Androida, ale są uważane za część ekosystemu Androida, urządzenie musi być zgodne z Androidem.
- artefakt
- Dziennik 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 dla urządzenia zgodnego z Androidem.
- Compatibility Test Suite (CTS)
Bezpłatny, komercyjny pakiet testów dostępny do pobrania jako plik binarny lub jako jako źródła w AOSP. CTS to zestaw testów jednostkowych zaprojektowanych tak, aby można je było zintegrować z Twoim codziennym przepływem pracy. Celem pakietu 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 wytycznymi:
- Jeśli test sprawdza poprawność funkcji lub zachowania interfejsu API frameworku i powinien być stosowany w przypadku wszystkich partnerów OEM, powinien być uwzględniony w CTS.
- Jeśli test ma wychwytywać regresje podczas tworzenia platformy, i mogą wymagać uprzywilejowanych uprawnień do przeprowadzenia i mogą być zależne w szczegółach implementacji (zgodnie z publikacją AOSP). Musi to być platforma test.
- 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 ściągania w C++. Zwykle pliki binarne GTest uzyskać dostęp do warstw abstrakcji niższego poziomu lub wykonać nieprzetworzony wskaźnik IPC w odniesieniu do różnych systemów usług Google. Podejście do testowania w przypadku GTest jest zwykle ściśle powiązane z testowanym serwisem. Tabela CTS zawiera platformę GTest.
- test z instrumentacją
specjalne środowisko wykonywania testów uruchamiane za pomocą polecenia
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 pomiarowy; Pakiet CTS zawiera testy z instrumentacją.- Logcat
Narzędzie wiersza poleceń tworzące dziennik komunikatów systemowych, w tym ślady stosu błędów oraz wysyłane komunikaty napisanych z poziomu aplikacji za pomocą klasy
Log
.- logowanie
Korzystanie z dziennika do śledzenia zdarzeń systemowych komputera, takich jak jako błędów. Rejestrowanie na Androidzie jest skomplikowane ze względu na różnorodność standardów używanych w narzędziu Logcat.
- test po przesłaniu
Test Androida, który jest wykonywany, gdy nowa poprawka zostanie zaakceptowana w głównym gałęzi jądra. Wpisanie
aosp_kernel
jako częściowej nazwy gałęzi pozwala może wyświetlić listę gałęzi jądra z dostępnymi wynikami. Na przykład wyniki adresu e-mailandroid-mainline
można znaleźć na stronie https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid- test przed przesłaniem
Test, który ma zapobiegać wprowadzaniu błędów do systemu i popularnych jąder.
- Federacja handlowa
Inaczej nazywany Tradefed (test ciągły). platforma zaprojektowana 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 z wykorzystaniem testów oraz automatyzacji testów warstwy abstrakcji sprzętowej (HAL) i jądra systemu operacyjnego.
Typy testów platform
Test platformy zwykle współdziała z co najmniej 1 systemem Android lub warstwy HAL, ćwiczy funkcji testowanego podmiotu i potwierdza ich poprawność wyniku testu. Test platformy może:
- (Typ 1) Wykorzystywanie interfejsów API frameworku do ćwiczeń za pomocą frameworku Androida. Określone interfejsy API
mogą obejmować:
- Publiczne interfejsy API przeznaczone dla aplikacji innych firm
- Ukryte interfejsy API przeznaczone dla aplikacji uprzywilejowanych, czyli interfejsy API systemu lub prywatne interfejsy API (
@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 listami HAL za pomocą niskopoziomowych interfejsów API 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, z którymi możesz się zapoznać, aby uzyskać bardziej szczegółowe informacje:
Jeśli nie znasz architektury Androida, zapoznaj się z artykułem Omówienie architektury.
Jeśli tworzysz urządzenie zgodne z Androidem, zapoznaj się z omówieniem programu zgodności z Androidem.
Aby zintegrować testy instrumentacji, testy funkcjonalne, testy danych i testy hosta JAR z usługą ciągłego testowania platformy, zapoznaj się z przepływem pracy dotyczącym tworzenia testów.
Aby wykrywać luki w zabezpieczeniach i zwiększać odporność urządzeń na nie, zapoznaj się z artykułem Testowanie bezpieczeństwa.
Więcej informacji o testowaniu implementacji HAL i jądra znajdziesz w tych artykułach: Vendor Test Suite (VTS) i infrastruktura
Aby dowiedzieć się więcej o testowaniu aplikacji, przeczytaj artykuł Podstawy testowania aplikacji na Androida i wykonaj Android w Kotlinie zaawansowanym 05.1: podstawy testowania, korzystając z próbek.
Poznaj podstawowe testy przed przesłaniem dostępne za pomocą punktów zaczepienia repozytorium. Te punkty zaczepienia mogą służyć do uruchamiania linterów, sprawdzania formatowania i jednostki wyzwalacza przed kontynuowaniem, na przykład przesłaniem zatwierdzenia. Te uchwyty są domyślnie wyłączone. Więcej informacji znajdziesz w artykule o wstępnym przesyłaniu plików AOSP Elementy przykuwające uwagę.
Więcej informacji znajdziesz w artykule Omówienie logowania.
Aby dowiedzieć się, jak debugować kod Androida, przeczytaj artykuł Debugowanie natywnego kodu platformy Androida