Testowanie mapowania

Ten artykuł zawiera krótkie wprowadzenie do mapowania testów oraz wyjaśnienie, jak rozpocząć konfigurowanie testów w ramach projektu Android Open Source Project (AOSP).

Informacje o mapowaniu testów

Mapowanie testowe to podejście oparte na Gerrit, które umożliwia programistom tworzenie przed przesłaniem i zasad testowania po przesłaniu bezpośrednio w drzewie źródłowym Androida. Pozostaw decyzji gałęzi i urządzeń do testowania w infrastrukturze testowej. Definicje testów mapowania to pliki JSON o nazwie TEST_MAPPING, które możesz umieścić w dowolnym katalogu źródłowym.

Atest może używać plików TEST_MAPPING do przeprowadzania testów przed przesłaniem w powiązanych katalogach. Dzięki mapowaniu testów możesz dodać ten sam zestaw testów do: weryfikacji przed przesłaniem z niewielką zmianą w drzewie źródłowym Androida.

Zapoznaj się z tymi przykładami:

Mapowanie testów polega na korzystaniu z testów Trade Federation (TF) do wykonywania testów i raportowania wyników.

Definiowanie grup testowych

Testuj grupy mapowania za pomocą grupy testowej. Nazwa grupy testów może być dowolnym ciągiem znaków. Na przykład presubmit może być nazwą grupy testów, które należy wykonać podczas sprawdzania zmian. Testy po przesłaniu mogą służyć do sprawdzania kompilacji po połączeniu zmian.

Reguły skryptu tworzenia pakietu

Aby można było korzystać z narzędzi testowych Federacji Handlowej, aby można było uruchamiać moduły testowe danej kompilacji, muszą mieć Zestaw test_suites dla utworu Soong lub LOCAL_COMPATIBILITY_SUITE w jednym z tych dwóch apartamentów:

  • general-tests jest przeznaczony do testów, które nie zależą od konkretnego urządzenia funkcji (takich jak sprzęt, który jest specyficzny dla dostawcy, którego większość urządzeń mają). Większość testów należy przeprowadzać w pakiecie general-tests, nawet jeśli są to do interfejsu ABI, transmisji bitów lub funkcji sprzętowych, takich jak HWASan ( osobny element docelowy test_suites dla każdego interfejsu ABI), a nawet jeśli muszą zostać uruchomione na urządzeniu.
  • device-tests służy do testowania, które zależą od możliwości urządzenia. Zazwyczaj te testy są dostępne w domenie vendor/. Zależnie od urządzenia odnosi się wyłącznie do funkcji, które są dostępne tylko na urządzeniu, więc ma to zastosowanie do testów JUnit i GTest (które zwykle powinny być oznaczone jako general-tests, nawet jeśli jest ona specyficzna dla interfejsu ABI).

Przykłady:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Konfigurowanie testów do uruchomienia w zestawie testów

Aby test został uruchomiony w ramach zestawu testów, wykonaj następujące czynności:

  • Nie może być dostawcy kompilacji.
  • Należy wyczyścić dane po jego zakończeniu, np. usuwając tymczasowe wygenerowanych podczas testu.
  • Musisz zmienić ustawienia systemu na domyślne lub pierwotne wartości.

  • Nie należy zakładać, że urządzenie jest w określonym stanie, na przykład z dostępem do roota. Uruchamianie większości testów nie wymaga uprawnień użytkownika root. Jeśli test wymaga uprawnień root, należy to określić za pomocą parametru RootTargetPreparer w AndroidTest.xml, jak w tym przykładzie:

    <target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Tworzenie testowych plików mapowania

W przypadku katalogu wymagającego zasięgu testu dodaj plik JSON TEST_MAPPING przypominający przykład. Te reguły zapewniają, że testy są uruchamiane w ramach weryfikacji przed przesłaniem, gdy w tym katalogu lub dowolnym z jego podkatalogów zostaną zmienione jakiekolwiek pliki.

Skorzystaj z przykładu

Oto przykładowy plik TEST_MAPPING (jest on w formacie JSON, ale obsługuje komentarze):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Ustawianie atrybutów

W przykładzie presubmit i postsubmit to nazwy poszczególnych elementów. grupę testową. Więcej informacji znajdziesz w artykule Definiowanie grup testowych o grupach testowych.

W wartości atrybutu name możesz podać nazwę modułu testowego lub nazwę testu integracji z Federacją Handlową (ścieżka zasobu do testowego pliku XML, np. uiautomator/uiautomator-demo). Pamiętaj, że w polu name nie można użyć klasy name ani metody testu name. Aby zawęzić zakres testów, użyj opcji takich jak include-filter. Zobacz include-filter przykładowe użycie.

Ustawienie host testu wskazuje, czy test dotyczy testu bez urządzeń działające na hoście. Wartość domyślna to false, co oznacza, że wartość testowa wymaga do działania urządzenia. Obsługiwane typy testów to HostGTest w przypadku binarnych plików GTest i HostTest w przypadku testów JUnit.

Atrybut file_patterns umożliwia skonfigurowanie listy ciągów wyrażeń regularnych. do dopasowania względnej ścieżki dowolnego pliku z kodem źródłowym (względem który zawiera plik TEST_MAPPING). W przykładzie test CtsWindowManagerDeviceTestCases działa we wstępnym przesłaniu tylko wtedy, gdy plik Java rozpoczyna się od Window lub Activity, który znajduje się w tym samym katalogu co TEST_MAPPING lub dowolnym z jego podkatalogów. Odwrócone ukośniki (\) muszą: bez zmian znaczenia, tak jak mają to miejsce w pliku JSON.

Atrybut imports pozwala uwzględnić testy w innych plikach TEST_MAPPING bez kopiowania treści. Do pliku importowanego ścieżki dołączone są też pliki TEST_MAPPING z folderów nadrzędnych. Mapowanie testowe zezwala importy zagnieżdżone; oznacza to, że 2 pliki TEST_MAPPING mogą się wzajemnie importować, mapowanie testowe może połączyć uwzględnione testy.

Atrybut options zawiera dodatkowe opcje wiersza poleceń Tradefed.

Aby uzyskać pełną listę dostępnych opcji dla danego testu, wykonaj:

tradefed.sh run commandAndExit [test_module] --help

Więcej informacji: Obsługa opcji w ramach Tradefed .

Przeprowadzanie testów w narzędziu Atest

Aby uruchomić reguły testowania przed przesłaniem lokalnie:

  1. Przejdź do katalogu z plikiem TEST_MAPPING.

  2. Uruchom polecenie:

    atest

Wszystkie testy przed przesłaniem skonfigurowane w plikach TEST_MAPPING bieżącego i jego katalogów nadrzędnych. Atest znajduje i uruchamia 2 testy przed przesłaniem (A i B).

Jest to najprostszy sposób na uruchomienie testów przed przesłaniem w plikach TEST_MAPPING w bieżącym katalogu roboczym (CWD) i katalogach nadrzędnych. Atest odnajduje i używa pliku TEST_MAPPING w katalogu głównym i wszystkich jego katalogach nadrzędnych.

Kod źródłowy struktury

Ten przykład pokazuje, jak skonfigurować pliki TEST_MAPPING w drzewie źródeł:

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Treść src/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Treść src/project_1/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Treść src/project_2/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Określanie katalogów docelowych

Możesz określić katalog docelowy do uruchamiania testów w plikach TEST_MAPPING w katalogu. To polecenie uruchamia 2 testy (A, B):

atest --test-mapping src/project_1

Przeprowadzanie reguł testowych po przesłaniu

Możesz też użyć tego polecenia do uruchomienia reguł testowania po przesłaniu TEST_MAPPING w src_path (domyślnie CWD) i w jego katalogach nadrzędnych:

atest [--test-mapping] [src_path]:postsubmit

Przeprowadzaj tylko testy, które nie wymagają urządzenia

Możesz użyć opcji --host w Atest, aby uruchomić tylko te testy skonfigurowane na hoście, które nie wymagają urządzenia. Bez tej opcji Atest uruchamia oba zarówno tych, które wymagają urządzenia, jak i tych działających na hoście, który nie wymaga urządzenia. Testy są przeprowadzane w 2 oddzielnych zestawach:

atest [--test-mapping] --host

Identyfikowanie grup testowych

Grupy testów możesz określić w komendach Atest. Podane niżej polecenie uruchamia wszystkie testy postsubmit dotyczące plików w katalogu src/project_1, który zawiera tylko jeden test (C).

Możesz też użyć funkcji :all do uruchomienia wszystkich testów niezależnie od grupy. To polecenie uruchamia 4 testy (A, B, C, X):

atest --test-mapping src/project_1:all

Uwzględnij podkatalogi

Domyślnie testy uruchamiane w TEST_MAPPING za pomocą Atest obejmują tylko testy przed przesłaniem skonfigurowane w pliku TEST_MAPPING w katalogu CWD (lub danym katalogu) i jego folderach nadrzędnych. Jeśli chcesz przeprowadzać testy we wszystkich TEST_MAPPING w podkatalogach, użyj opcji --include-subdir, aby wymusza uwzględnienie tych testów przez Atest.

atest --include-subdir

Bez opcji --include-subdir Atest wykonuje tylko test A. Za pomocą Opcja --include-subdir, Atest przeprowadza 2 testy (A i B).

Komentarze na poziomie wiersza

Możesz dodać komentarz w formacie // na poziomie wiersza, aby rozwinąć TEST_MAPPING z opisem ustawienia. ATest i Federacja handlu przetwarzają TEST_MAPPING do prawidłowego formatu JSON bez komentarzy. Aby plik JSON był przejrzysty, obsługiwane są tylko komentarze w formacie // na poziomie wiersza.

Przykład:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}