Mapowanie testowe

To jest krótkie wprowadzenie do map testów i wyjaśnienie, jak rozpoczął konfigurowanie testów w projekcie Android Open Source Project (AOSP).

Informacje o mapowaniu testów

Mapowanie testowe to podejście oparte na Gerrit, które umożliwia programistom tworzenie i reguł testowania po przesłaniu bezpośrednio w drzewie źródłowym Androida. 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.

Narzędzie Atest może używać plików TEST_MAPPING do uruchamiania testów przed przesłaniem w powiązanych katalogów. 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.

Zobacz te przykłady:

Mapowanie testowe opiera się na Narzędzia testowe federacji handlowej (TF) testów związanych z wykonaniem i raportowaniem wyników.

Zdefiniuj grupy testowe

Testuj grupy mapowania za pomocą grupy testowej. Grupa testowa może mieć nazwę dowolnego ciągu. Na przykład presubmit może być nazwą grupy testów, do której uruchamiania podczas weryfikowania zmian. Za pomocą postsubmit można sprawdzić, po scaleniu kompilacji.

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 dla danej kompilacji, muszą one mieć Zestaw test_suites dla zestawu Utwór lub LOCAL_COMPATIBILITY_SUITE do jednego z tych dwóch apartamentów:

  • general-tests służy do testów, które nie zależą od funkcji urządzenia (takich jak sprzęt producenta, którego nie ma większość urządzeń). Większość testów powinna być zawarta w pakiecie general-tests, nawet jeśli dotyczą one konkretnego ABI, liczby bitów lub funkcji sprzętowych, takich jak HWASan (dla każdego ABI jest osobny element docelowy test_suites), a także nawet jeśli muszą być uruchamiane 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 w zestawie testowym

Aby test mógł być wykonywany w ramach zestawu testów:

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

  • Nie należy zakładać, że urządzenie jest w określonym stanie, na przykład z dostępem do roota. Większość testów nie wymaga uprawnień roota. Jeśli test musi wymagać pierwiastka, powinien określać, że w parametrze RootTargetPreparer 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. Dzięki tym regułom testy będą przeprowadzane wstępne przesyłanie sprawdza, czy plik został dotknięty tym katalogiem lub jego podkatalogi.

Skorzystaj z przykładu

Oto przykładowy plik TEST_MAPPING (w formacie JSON, ale z komentarzami obsługiwane):

{
  "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"
    }
  ]
}

Ustaw atrybuty

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

Możesz ustawić nazwę modułu testu lub testu integracji federacji handlowej. nazwa (ścieżka zasobu do testowego pliku XML, np. uiautomator/uiautomator-demo) w wartości atrybutu name. Pamiętaj, że pole name nie może użyj klasy name lub metody testowej name. Aby zawęzić zakres testów, użyj opcji takich jak include-filter. Zobacz (przykładowe wykorzystanie: include-filter).

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 za Pliki binarne GTest i HostTest dla JUnit testów.

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 Plik TEST_MAPPING lub dowolny z jego podkatalogów został zmieniony. Ukośnik lewy „” wymaga zmiany znaczenia, tak jak w pliku JSON.

Atrybut imports pozwala uwzględnić testy w innych plikach TEST_MAPPING bez kopiowania treści. Pliki TEST_MAPPING w nadrzędnej z importowaną ścieżką. 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ę opcji dostępnych w przypadku danego testu, uruchom polecenie:

tradefed.sh run commandAndExit [test_module] --help

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

Przeprowadzanie testów w narzędziu Atest

Aby lokalnie wykonać reguły testu wstępnego:

  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 lokalizuje i wykorzystuje plik TEST_MAPPING w CWD oraz wszystkie jego elementy nadrzędne i katalogów.

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ść strony src/project_2/TEST_MAPPING:

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

Określ katalogi docelowe

Możesz określić katalog docelowy do uruchamiania testów w plikach TEST_MAPPING w katalogu. To polecenie uruchamia 2 testy (A i 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

Uruchamianie tylko testów, 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 testy, te, które wymagają urządzenia i te, które działają na hoście, i nie wymagają urządzenia. testy są przeprowadzane w dwóch osobnych zestawach:

atest [--test-mapping] --host

Określ grupy testowe

Grupy testowe możesz określić w poleceniu Atest. Uruchomiono następujące polecenie wszystkich testów postsubmit związanych z plikami w katalogu src/project_1, które 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 w trybie TEST_MAPPING z użyciem Atest są uruchamiane tylko przed przesłaniem testów skonfigurowanych w pliku TEST_MAPPING w CWD (lub danego katalogu) i jego katalogów 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 uruchamia tylko test A. W przypadku opcji --include-subdir Atest przeprowadza 2 testy (A i B).

Obsługa komentarzy na poziomie wiersza

Możesz dodać komentarz w formacie // na poziomie wiersza, aby rozwinąć TEST_MAPPING z opisem ustawienia. ATest i federacja handlowa wstępnie przetwórz TEST_MAPPING do prawidłowego formatu JSON bez komentarzy. Aby zachować czysty plik JSON, tylko komentarz w formacie // na poziomie wiersza jest obsługiwane.

Przykład:

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