Inicjowanie klienta Repo
Postępuj zgodnie z instrukcjami pobierania źródła, aby pobrać
i skompiluj kod źródłowy Androida. Uruchamiając polecenie repo init
, podaj w polu zapytania
konkretna gałąź CTS za pomocą metody -b
. Dzięki temu zmiany w tagu CTS zostaną uwzględnione
w kolejnych wersjach CTS.
Ten przykładowy kod pokazuje, jak używać repo init
.
mkdir android11-tests-dev && cd android11-tests-dev && repo init -c -u https://android.googlesource.com/platform/manifest -b android11-tests-dev --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M && repo sync -c -j8
Tworzenie i uruchamianie CTS
Wykonaj te polecenia, aby utworzyć CTS i rozpocząć interaktywną Konsola CTS:
cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed
W konsoli CTS wpisz:
tf> run cts --plan CTS
Zapisywanie testów CTS
Testy CTS wykorzystują JUnit i interfejsy API do testowania Androida. Zapoznaj się z
Testuj
aplikacji
i testach istniejących w katalogu cts/tests
.
W testach CTS stosowane są w większości te same konwencje co w innych testach na Androidzie.
CTS działa na wielu urządzeniach produkcyjnych, więc testy muszą być te reguły:
- Weź pod uwagę różne rozmiary ekranu, orientacje i układy klawiatury.
- Używaj tylko publicznych metod interfejsu API. Inaczej mówiąc, unikaj wszystkich klas, metod i pól.
z adnotacją
hide
. - Unikaj korzystania z układów widoku i wymiarów zasobów, które mogą być niedostępne w niektórych urządzenia.
- Nie polegaj na uprawnieniach użytkownika root.
Dodaj adnotację w Javie
Jeśli test potwierdzi działanie interfejsu API, dodaj do kodu testowego adnotacje @ApiTest
i listę
wszystkich interfejsów API używanych w polu apis
. Użyj odpowiedniego formatu spośród
następujące przykłady:
Typ interfejsu API | Format adnotacji | Uwagi |
---|---|---|
Metoda | android.example.ClassA#methodA |
Najczęstszy przypadek użycia. |
Metoda z parami klucz-wartość | android.example.ClassB#methodB(KeyA) |
Używaj tylko wtedy, gdy test korzysta z metody API do weryfikacji pola, na przykład w tym przykładzie. |
Pole | android.example.KlasaC#PoleA | Używaj tylko wtedy, gdy test weryfikuje bezpośrednio pole interfejsu API, np. w tym przykładzie. |
Jeśli test potwierdzi zgodność z CDD, podaj jego identyfikator (w tym sekcję CDD)
identyfikator i identyfikator wymagania) wartością @CddTest
w kodzie testowym CTS, tak jak to widać w polu
z tego przykładu. W komunikacie o zobowiązaniu wspomnij, które wymagania CDD są sprawdzane przez
zgodnie z identyfikatorami wymagań CDD. Identyfikatory wymagań CDD są kombinacją identyfikatorów sekcji
i identyfikatora wymagania, połączone ukośnikiem (/), jak w punkcie 7.3.1/C-1-1.
/**
* Verify Passpoint configuration management APIs for a Passpoint
* @throws Exception
*/
@CddTest(requirement="7.4.2.3/C-1-1,C-2-1")
public void testAddPasspointConfigWithUserCredential() throws Exception {
if (!WifiFeature.isWifiSupported(getContext())) {
// skip the test if WiFi is not supported
return;
} testAddPasspointConfig(generatePasspointConfig(generateUserCredential()));
}
W przypadku weryfikatora CTS oznacz każdą aktywność w elemencie AndroidManifest.xml
znacznikiem
odpowiedni identyfikator CDD. Formaty pól wartości są podobne do formatów adnotacji Java w
CTS. W komunikacie o zatwierdzeniu wskaż, które wymagania CDD są egzekwowane, podając CDD
identyfikatora wymagania.
<activity>
......
<!-- OPTIONAL: Add a meta data attribute to indicate CDD requirements. -->
<meta-data android:name="cdd_test" android:value="7.4.1/C-4-1" />
<!-- OPTIONAL: Add a meta data attribute to indicate APIs being tested. -->
<meta-data android:name="api_test"
android:value="com.example.MyClass#myMethod" />
<!-- OPTIONAL: Add a metadata attribute to indicate the reason why the test doesn't enforce any CDD requirement but still useful in CTS-V. -->
<meta-data android:name="non_compliance_test"
android:value="detailed reasons" />
</activity>
W komunikacie zatwierdzenia
Jasno wyjaśnij, dlaczego musisz dodać test, i dodaj odpowiednie linki pomocy. Do CTS-D testów, podaj link do propozycji testu utworzonej w narzędziu Google Issue Tracker w ramach procesu przesyłania CTS-D.
Tworzenie abonamentu podrzędnego
Możesz na przykład dodać plik SubPlan.xml w
android-cts/subplans
w następujący sposób:
<?xml version="1.0" encoding="utf-8" standalone="no"?> <SubPlan version="2.0"> <Entry include="CtsSystemIntentTestCases" /> <Entry include="CtsSystemUiHostTestCases" /> <Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospFileContexts" /> <Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospServiceContexts" /> </SubPlan>
Aby uruchomić abonament podrzędny:
run cts --subplan aSubPlan
Format wpisu abonamentu podrzędnego to:
Include a module name as follows: <Entry include="MODULE_NAME" /> Include a package: <Entry include="MODULE_NAME PACKAGE_NAME" /> Include a class: <Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME" /> Include an individual test: <Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME#TEST_NAME" />
Testowanie nazewnictwa i lokalizacji
Większość przypadków testowych CTS jest kierowana na określoną klasę w interfejsie Android API. Te testy
mają nazwy pakietów Javy z sufiksem cts
i nazwy klas ze znakiem
Sufiks: Test
. Każdy przypadek testowy składa się z kilku testów, z których każdy
zwykle jest wykorzystywana określona metoda dotycząca testowanych zajęć.
Testy te znajdują się w strukturze katalogów, w której testy są pogrupowane według kategorii:
różne kategorie, takie jak „widżety”, lub „widoki”.
Na przykład test CTS pakietu Javy
android.widget.TextView
to
android.widget.cts.TextViewTest
z pakietem Java o nazwie
android.widget.cts
z nazwą klasy
TextViewTest
- Nazwa pakietu Java
Nazwa pakietu Javy na potrzeby testów CTS to nazwa pakietu klasy, którą testujesz, po której następuje ciąg znaków.cts
W naszym przykładzie nazwa pakietu toandroid.widget.cts
- Nazwa klasy
Nazwa klasy w przypadku testów CTS to nazwa klasy testowanej za pomocą przycisku „Test” . Dla: Jeśli test jest kierowany naTextView
, nazwa klasy powinna wyglądać tak:TextViewTest
- Nazwa modułu (tylko CTS w wersji 2)
CTS w wersji 2 porządkuje testy według modułu. Nazwa modułu jest zwykle drugim ciągiem nazwy pakietu Javy (w naszym np.widget
).
Struktura katalogu i przykładowy kod zależą od tego, czy używasz CTS v1 czyli CTS v2.
CTS wersja 1
W przypadku Androida 6.0 lub starszego użyj CTS v1. W przypadku CTS v1 przykładowy kod znajduje się pod adresem
cts/tests/tests/example
Struktura katalogów w testach CTS w wersji 1 wygląda tak:
cts/ tests/ tests/ package-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
CTS wersja 2
W przypadku Androida 7.0 lub nowszego użyj CTS v2. Aby dowiedzieć się więcej, zobacz przykładowy test w programie Android Open Source Project (AOSP).
Struktura katalogu CTS v2 wygląda tak:
cts/ tests/ module-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
Nowe przykładowe pakiety
Podczas dodawania nowych testów może nie być istniejącego katalogu, w którym można umieścić test. W takich przypadkach musisz utworzyć katalog i skopiować odpowiednie przykładowe pliki.
CTS wersja 1
Jeśli używasz CTS w wersji 1, zapoznaj się z przykładem w sekcji
cts/tests/tests/example
i utwórz nowy katalog. Oprócz tego:
dodaj nazwę modułu nowego pakietu z pola Android.mk
do CTS_COVERAGE_TEST_CASE_LIST
w
cts/CtsTestCaseList.mk
Aplikacja build/core/tasks/cts.mk
używa tego pliku Makefile
by połączyć wszystkie testy i utworzyć ostateczny pakiet CTS.
CTS wersja 2
Korzystanie z przykładowego testu
/cts/tests/sample/
, aby szybko rozpocząć nowy moduł testowy, wykonując te czynności:
- Aby utworzyć katalog testowy i skopiować przykładowe pliki, uruchom polecenie:
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
- Przejdź do elementu
cts/tests/module-name
i zastąp wszystkie wystąpienia „[S]Dużo” z zalecaną konwencję nazewnictwa powyżej. - Zaktualizuj aplikację
SampleDeviceActivity
, aby przetestować funkcję, którą testujesz. - Zaktualizuj zasadę
SampleDeviceTest
, aby mieć pewność, że aktywność zakończy się powodzeniem, lub dzienniki błędów.
Dodatkowe katalogi
Inne katalogi Androida, takie jak assets
, jni
,
Możesz również dodać libs
i res
.
Aby dodać kod JNI:
utwórz katalog w katalogu głównym projektu obok instancji src
z natywnym
i Android.mk
.
Ma on zwykle następujące ustawienia:
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := libCtsSample_jni # don't include this package in any target LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := list of source code files LOCAL_C_INCLUDES := $(JNI_H_INCLUDE) # Tag this module as a cts test artifact LOCAL_COMPATIBILITY_SUITE := cts LOCAL_SHARED_LIBRARIES := libnativehelper LOCAL_SDK_VERSION := current include $(BUILD_SHARED_LIBRARY)
Plik Android.mk
Na koniec zmodyfikuj plik Android.mk
w katalogu głównym
w celu utworzenia kodu natywnego i korzystania z niego, jak pokazano poniżej:
# All tests should include android.test.runner. LOCAL_JAVA_LIBRARIES := android.test.runner # Includes the jni code as a shared library LOCAL_JNI_SHARED_LIBRARIES := libCtsSample_jni # Include for InstrumentationCtsTestRunner LOCAL_STATIC_JAVA_LIBRARIES := ctstestrunner... LOCAL_SDK_VERSION := currentinclude $(BUILD_CTS_PACKAGE) #Tells make to look in subdirectories for more make files to include include $(call all-makefiles-under,$(LOCAL_PATH))
Naprawianie lub usuwanie testów
Oprócz dodawania nowych testów możesz też
usuń testy z adnotacjami BrokenTest
lub KnownFailure
.
Wprowadzanie zmian
Podczas przesyłania poprawek CTS lub VTS w AOSP wybierz gałąź programistyczną zależnie od tego, do których poziomów interfejsu API ma zastosowanie poprawka.
-
W przypadku zmian, które mają zastosowanie do wielu poziomów interfejsu API, najpierw
opracować poprawkę w systemie
aosp/main
i wybrać najbardziej gałęzi testowej. Zezwól automatycznemu narzędziu na scalenie zmian w kolejnym kroku Oddziały testowe AOSP. Zobacz Harmonogram publikacji i informacje o oddziałach na liście oraz automatyczne scalanie informacji o ścieżkach. - W przypadku zmian, które są specyficzne dla określonego poziomu interfejsu API, zaprogramuj lub wybierz wybór. wprowadź zmiany w prawidłowej gałęzi testowej za pomocą polecenia NIE ŁĄCZUJ lub RESTRICT AUTOMERGE w komunikacie zatwierdzenia.
Postępuj zgodnie z procedurą przesyłania poprawek. zmiany w panelu CTS. Weryfikator zapozna się z Twoją zmianą i odpowiednio ją sprawdzi.
Harmonogram wersji i informacje o gałęziach
Wersje CTS są zgodne z tym harmonogramem.
Wersja | Poziom interfejsu API | Oddział | Częstotliwość |
---|---|---|---|
14 | 34 | deweloper-testów-android14 | Co kwartał |
13 | 33 | deweloper-android13-tests-dev | Co kwartał |
12 l | 32 | android12L-tests-dev, | Co kwartał |
12 | 31 | deweloper-android12-tests-dev | Co kwartał |
11 | 30 | android11-tests-dev, | Co kwartał |
Nie planujemy kolejnych wersji w wersjach 10.0, 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3 i 4.2. |
Ważne daty w trakcie premiery
- Koniec pierwszego tygodnia: kod zablokowany. Zmiany scalone w gałęzi do czasu, gdy rozpatrujemy kwestię blokady kodu w nadchodzącej wersji CTS. zgłoszenia do oddziału po zamrożeniu kodu lub po zgłoszeniu kandydata do władzy. wersji, są uwzględniane przy następnej wersji.
- Drugi lub trzeci tydzień: grupa CTS jest publikowana w AOSP
Proces automatycznego scalania
Gałęzie deweloperskie CTS zostały skonfigurowane tak, aby zmiany przesyłane do każdej z nich były automatycznie scala się z wyższymi gałęziami.
W przypadku zmian bezpośrednio w gałęzi programistycznej testu AOSP ścieżka automatycznego scalania to:
android11-tests-dev
android12-tests-dev
>
android12L-tests-dev
android13-tests-dev
>
android14-tests-dev
aosp/main
W przypadku zmian tylko w następnej wersji Androida ścieżka automatycznego scalania to:
aosp/main
<Internal git/main>
Jeśli nie uda się prawidłowo scalić listy zmian, wysyłany jest autor poprawki. e-maila z instrukcjami, jak rozwiązać konflikt. W większości autor poprawki może skorzystać z instrukcji w celu pominięcia automatycznego scalania kolidującej listy zmian.
Jeśli starsza gałąź wymaga zmian, poprawka musi być wybrane z nowszej gałęzi.