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

Mapowanie testowe

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 mapowania testowego to pliki JSON o nazwie TEST_MAPPING, które można 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 w jednym z tych dwóch apartamentów:

  • general-tests jest przeznaczony do testów, które nie zależą od konkretnego urządzenia (np. sprzętowy sprzęt, którego większość urządzeń nie obsługuje, 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 w zestawie testowym

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

  • 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. Uruchamianie większości testów nie wymaga uprawnień użytkownika root. 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ępna analiza sprawdza, czy pliki zostały dotknięte 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 elementów. grupę testową. Więcej informacji znajdziesz w artykule Definiowanie grup testowych o grupach testowych.

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 lokalizuje i uruchamia 2 testy dla wstępnego przesłania (A i B).

To najprostszy sposób na przeprowadzanie testów przed przesłaniem w usłudze TEST_MAPPING w bieżącym katalogu roboczym 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 drzewo źródłowe:

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ś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

Uruchamianie reguł testów 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 dla Atest, aby uruchomić tylko te testy, względem których zostały skonfigurowane hosta, który nie wymaga 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. Poniżej 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. Za pomocą Opcja --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"
    }
  ]
}