Programowanie CTS

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.

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:

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 to android.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 na TextView, 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:

1. 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

2. Przejdź do elementu cts/tests/module-name i zastąp wszystkie wystąpienia „[S]Dużo” z zalecaną konwencję nazewnictwa powyżej.
3. Zaktualizuj aplikację SampleDeviceActivity, aby przetestować funkcję, którą testujesz.
4. 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.

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.