AOSP udostępnia kilka narzędzi i zestawów testów do testowania różnych części implementacji. Zanim przejdziesz dalej do tej sekcji, powinieneś zapoznać się z następującymi terminami:
- Urządzenie kompatybilne z Androidem
- Urządzenie, na którym można uruchomić dowolną aplikację innej firmy napisaną przez zewnętrznych programistów przy użyciu zestawów SDK i NDK systemu Android. Urządzenia kompatybilne z Androidem muszą spełniać wymagania dokumentu definicji zgodności (CDD) i przejść pakiet testów zgodności (CTS) . Urządzenia zgodne z Androidem mogą uczestniczyć w ekosystemie Androida, co obejmuje potencjalną licencję na Sklep Google Play, potencjalną licencję na pakiet aplikacji i interfejsów API Google Mobile Services (GMS) oraz korzystanie ze znaku towarowego Android. Każdy może korzystać z kodu źródłowego Androida, ale aby urządzenie mogło zostać uznane za część ekosystemu Androida, musi być zgodne z Androidem.
- artefakt
- Artefakty to dzienniki związane z kompilacją, które umożliwiają lokalne rozwiązywanie problemów.
- Dokument definicji zgodności (CDD)
- Dokument zawierający listę wymagań programowych i sprzętowych dla urządzenia zgodnego z systemem Android.
- Zestaw testów zgodności (CTS)
Bezpłatny zestaw testów klasy komercyjnej, dostępny do pobrania w formacie binarnym lub jako źródło w AOSP. CTS to zestaw testów jednostkowych zaprojektowanych tak, aby można je było zintegrować z codziennym przepływem pracy. Celem CTS jest ujawnienie niezgodności i zapewnienie kompatybilności oprogramowania przez cały proces rozwoju.
Testy CTS i platformy nie wykluczają się wzajemnie. Oto kilka ogólnych wskazówek:
- Jeśli test potwierdza poprawność funkcji lub zachowań frameworkowego interfejsu API i powinien być egzekwowany u partnerów OEM, powinien odbywać się w CTS.
- Jeśli test ma na celu wykrycie regresji podczas tworzenia platformy i może wymagać uprzywilejowanych uprawnień do przeprowadzenia i może zależeć od szczegółów implementacji (opublikowanych w AOSP), powinien to być test platformy.
- Usługi mobilne Google (GMS)
Zbiór aplikacji i interfejsów API Google, które można preinstalować na urządzeniach.
- Test Google (GTest)
GTest to framework do testowania i szyderstwa w C++. Pliki binarne GTest zazwyczaj uzyskują dostęp do warstw abstrakcji niższego poziomu lub wykonują surowe IPC w stosunku do różnych usług systemowych. Podejście testowe w GTest jest zwykle ściśle powiązane z testowaną usługą. CTS zawiera framework GTest.
- próba oprzyrządowania
Test oprzyrządowania zapewnia specjalne środowisko wykonywania testów uruchamiane komendą
am instrument
, w którym docelowy proces aplikacji jest uruchamiany ponownie i inicjowany z podstawowym kontekstem aplikacji, a wątek oprzyrządowania jest uruchamiany wewnątrz maszyny wirtualnej procesu aplikacji. CTS zawiera testy oprzyrządowania.- Logcat
Logcat to narzędzie wiersza poleceń, które tworzy dziennik komunikatów systemowych, w tym ślady stosu w przypadku zgłoszenia błędu przez urządzenie oraz komunikaty napisane z aplikacji za pomocą klasy
Log
.- Logowanie
Rejestrowanie oznacza używanie dziennika do śledzenia zdarzeń w systemie komputerowym, takich jak błędy. Logowanie w systemie Android jest skomplikowane ze względu na mieszankę stosowanych standardów, które są łączone w narzędziu Logcat.
- test po złożeniu
Testy po przesłaniu systemu Android są przeprowadzane, gdy nowa łatka jest zatwierdzona we wspólnej gałęzi jądra. Wpisując
aosp_kernel
jako częściową nazwę gałęzi, możesz zobaczyć listę gałęzi jądra z dostępnymi wynikami. Na przykład wyniki dlaandroid-mainline
można znaleźć pod adresem https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid .- wstępne przesłanie testu
Testy wstępne służą do zapobiegania wprowadzaniu błędów do zwykłych jąder.
- Federacja Handlowa
Trade Federation, zwana także Tradefed, to platforma testów ciągłych przeznaczona do przeprowadzania testów na urządzeniach z systemem Android. Na przykład Tradefed służy do uruchamiania testów zestawu testów zgodności i zestawu testów dostawcy.
- Zestaw testów dostawców (VTS)
Pakiet Android Vendor Test Suite (VTS) zapewnia szerokie możliwości testowania systemu Android, promuje proces programowania oparty na testach oraz automatyzuje testowanie HAL i jądra systemu operacyjnego.
Typy testów platformy
Test platformy zazwyczaj wchodzi w interakcję z jedną lub większą liczbą usług systemu Android lub warstw abstrakcji sprzętu (HAL), sprawdza funkcjonalności testowanego obiektu i potwierdza poprawność wyniku testu. Test platformy może:
- (typ 1) API frameworka do ćwiczeń przy użyciu frameworka Android. Konkretne wykorzystywane interfejsy API mogą obejmować:
- Publiczne interfejsy API przeznaczone dla aplikacji innych firm
- Ukryte interfejsy API przeznaczone dla aplikacji uprzywilejowanych, mianowicie systemowe interfejsy API lub prywatne interfejsy API (
@hide
, or
chroniony,
pakiet prywatny`)
- (typ 2) Wywołuj usługi systemu Android bezpośrednio przy użyciu surowego segregatora lub serwerów proxy IPC.
- (typ 3) Bezpośrednia interakcja z warstwami HAL przy użyciu niskopoziomowych interfejsów API lub interfejsów IPC.
Testy typu 1 i 2 to zazwyczaj testy oprzyrządowania, podczas gdy testy typu 3 to zwykle testy GT.
Co dalej?
Poniżej znajduje się lista kolejnych dokumentów, z którymi możesz się zapoznać:
Jeśli nie zapoznałeś się z architekturą Androida, zobacz Omówienie architektury .
Jeśli tworzysz urządzenie zgodne z systemem Android, zapoznaj się z omówieniem programu zgodności z systemem Android .
Aby zintegrować testy instrumentalne, funkcjonalne, metryczne i testy hosta JAR z usługą ciągłego testowania platformy, zobacz Przepływ pracy podczas tworzenia testów .
Aby wykryć i zabezpieczyć swoje urządzenia przed lukami, zobacz Testowanie bezpieczeństwa .
Aby dowiedzieć się więcej na temat testowania implementacji HAL i jądra, zobacz Vendor Test Suite (VTS) i infrastruktura .
Aby przetestować aplikacje, przeczytaj Podstawy testowania aplikacji na Androida i przeprowadź zaawansowany Android w Kotlin 05.1:Podstawy testowania, korzystając z dostarczonych przykładów .
Dowiedz się o podstawowych testach przed przesłaniem dostępnych za pośrednictwem haków repo. Tych haków można używać do uruchamiania lintersów, sprawdzania formatowania i wyzwalania testów jednostkowych przed kontynuowaniem, na przykład przesyłaniem zatwierdzenia. Te hooki są domyślnie wyłączone. Więcej informacji można znaleźć w temacie Haki AOSP Preupplaod .
Więcej informacji na temat rejestrowania można znaleźć w artykule Omówienie rejestrowania .
Aby dowiedzieć się, jak debugować kod Androida, zobacz Debugowanie kodu platformy natywnej .