Mapowanie testowe

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

Informacje o mapowaniu testowym

Mapowanie testów to podejście oparte na Gerrit, które umożliwia programistom tworzenie reguł testowych przed i po przesłaniu bezpośrednio w drzewie źródłowym Androida i pozostawienie decyzji dotyczących testowania oddziałów i urządzeń samej infrastrukturze testowej. Definicje mapowania testów to pliki JSON o nazwie TEST_MAPPING, które można umieścić w dowolnym katalogu źródłowym.

Atest może używać plików TEST_MAPPING do uruchamiania testów przed przesłaniem w powiązanych katalogach. Dzięki mapowaniu testów możesz dodać ten sam zestaw testów, aby wstępnie przesłać kontrole, wprowadzając prostą zmianę w drzewie źródeł Androida.

Zobacz te przykłady:

Dodaj testy przed przesłaniem do TEST_MAPPING dla Services.core

Dodaj wstępne testy do TEST_MAPPING dla narzędzi/zręczności za pomocą importu

Mapowanie testów opiera się na wiązce testowej Federacji Handlowej (TF) w zakresie wykonywania testów i raportowania wyników.

Zdefiniuj grupy testowe

Testowanie grup mapujących testy za pośrednictwem grupy testowej . Nazwa grupy testowej może być dowolnym ciągiem. Na przykład wstępne przesłanie może obejmować wykonanie grupy testów podczas sprawdzania poprawności zmian. Testy przeprowadzane po przesłaniu mogą służyć do sprawdzania poprawności kompilacji po połączeniu zmian.

Reguły skryptu kompilacji pakietu

Aby zespół testowy Federacji Handlowej mógł uruchomić moduły testowe mapowania testów dla danej kompilacji, moduły te muszą mieć ustawiony test_suite dla Soong lub LOCAL_COMPATIBILITY_SUITE dla Make w jednym z tych dwóch zestawów:

  • testy ogólne — testy niezależne od funkcjonalności konkretnego urządzenia (takie jak sprzęt specyficzny dla dostawcy, którego nie ma większość urządzeń). Większość testów powinna znajdować się w zestawie testów ogólnych, nawet jeśli są specyficzne dla jednego ABI, bitowości lub funkcji sprzętowych, takich jak HWASan (istnieje oddzielny cel test_suites dla każdego ABI) i nawet jeśli muszą działać na urządzeniu.
  • testy urządzeń - testy zależne od funkcjonalności specyficznej dla urządzenia. Zazwyczaj testy te można znaleźć w sekcji vendor/ . Ponieważ „specyficzne dla urządzenia” nie odnosi się do funkcjonalności ABI lub SoC, które inne urządzenia mogą mieć lub nie, ale tylko do funkcjonalności, która jest unikalna dla urządzenia , dotyczy to testów JUnit w takim samym stopniu, jak testów natywnych GTest (które zwykle powinny być general-tests nawet jeśli są specyficzne dla ABI).

Przykłady:

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

Skonfiguruj testy do uruchomienia w zestawie testów

Aby test mógł zostać uruchomiony w zestawie testów, należy wykonać następujące czynności:

  • nie może mieć żadnego dostawcy kompilacji.
  • należy posprzątać po jego zakończeniu, na przykład usuwając wszelkie pliki tymczasowe wygenerowane podczas testu.
  • zmień ustawienia systemowe na wartości domyślne lub oryginalne.
  • nie powinien zakładać, że urządzenie jest w określonym stanie, np. gotowe do rootowania. Większość testów nie wymaga uprawnień roota do uruchomienia. Jeśli test musi wymagać rootowania, powinien to określić za pomocą RootTargetPreparer w pliku AndroidTest.xml , jak w poniższym przykładzie:
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Utwórz testowe pliki mapowania

W przypadku katalogu wymagającego pokrycia testowego wystarczy dodać plik JSON TEST_MAPPING, przypominający poniższy przykład. Reguły te zapewnią, że testy zostaną uruchomione podczas kontroli przed przesłaniem, gdy zostaną dotknięte jakiekolwiek pliki w tym katalogu lub którymkolwiek z jego podkatalogów.

Podążaj za przykładem

Oto przykładowy plik TEST_MAPPING (jest 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": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Ustaw atrybuty

W powyższym przykładzie presubmit i postsubmit to nazwy każdej grupy testowej . Aby uzyskać więcej informacji na temat grup testowych, zobacz Definiowanie grup testowych .

Nazwę modułu testowego lub nazwę testu integracyjnego Federacji Handlowej (ścieżka zasobu do testowego pliku XML, np. uiautomator/uiautomator-demo ) można ustawić w wartości atrybutu name . Uwaga: pole nazwy nie może zawierać name klasy ani name metody testowej. Aby zawęzić liczbę testów do uruchomienia, możesz użyć tutaj opcji takich jak include-filter . Zobacz ( użycie przykładowego filtra włączającego ).

Ustawienie hosta testu wskazuje, czy test jest testem bezurządzeniowym działającym na hoście, czy nie. Wartość domyślna to false , co oznacza, że ​​do uruchomienia testu wymagane jest urządzenie. Obsługiwane typy testów to HostGTest dla plików binarnych GTest i HostTest dla testów JUnit.

Atrybut file_patterns umożliwia ustawienie listy ciągów wyrażeń regularnych odpowiadających względnej ścieżce dowolnego pliku kodu źródłowego (względem katalogu zawierającego plik TEST_MAPPING). W powyższym przykładzie test CtsWindowManagerDeviceTestCases zostanie uruchomiony przed przesłaniem tylko wtedy, gdy dowolny plik Java zaczynający się od okna lub działania, który istnieje w tym samym katalogu pliku TEST_MAPPING lub w dowolnym z jego podkatalogów, zostanie zmieniony. Ukośniki odwrotne \ muszą być zmienione, tak jak w pliku JSON.

Atrybut imports umożliwia dołączenie testów do innych plików TEST_MAPPING bez kopiowania zawartości. Należy pamiętać, że pliki TEST_MAPPING w katalogach nadrzędnych importowanej ścieżki również zostaną uwzględnione. Mapowanie testowe umożliwia import zagnieżdżony; oznacza to, że dwa pliki TEST_MAPPING mogą się wzajemnie importować, a mapowanie testów może poprawnie scalić dołączone testy.

Atrybut opcji zawiera dodatkowe opcje wiersza poleceń TradeFed.

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

tradefed.sh run commandAndExit [test_module] --help

Więcej szczegółów na temat działania opcji można znaleźć w części Obsługa opcji TradeFed .

Przeprowadź testy za pomocą Atest

Aby lokalnie wykonać reguły testu przed przesłaniem:

  1. Przejdź do katalogu zawierającego plik TEST_MAPPING.
  2. Uruchom polecenie:
atest

Zostaną uruchomione wszystkie testy wstępne skonfigurowane w plikach TEST_MAPPING bieżącego katalogu i jego katalogów nadrzędnych. Atest zlokalizuje i przeprowadzi dwa testy przed przesłaniem (A i B).

Jest to najprostszy sposób uruchomienia testów przed przesłaniem w plikach TEST_MAPPING w bieżącym katalogu roboczym (CWD) i katalogach nadrzędnych. Atest zlokalizuje i użyje pliku TEST_MAPPING w CWD i wszystkich jego katalogach nadrzędnych.

Struktura kodu źródłowego

Poniższy przykład pokazuje, jak można skonfigurować pliki TEST_MAPPING w drzewie źródłowym.

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

Zawartość src/TEST_MAPPING :

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

Zawartość src/project_1/TEST_MAPPING :

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

Zawartość src/project_2/TEST_MAPPING :

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

Określ katalogi docelowe

Możesz określić katalog docelowy, aby uruchomić testy w plikach TEST_MAPPING w tym katalogu. Poniższe polecenie uruchomi dwa testy (A, B).

atest --test-mapping src/project_1

Uruchom reguły testu po przesłaniu

Możesz także użyć tego polecenia, aby uruchomić reguły testu po przesłaniu zdefiniowane w TEST_MAPPING w src_path (domyślnie CWD) i jego katalogach nadrzędnych:

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

Wykonuj tylko testy, które nie wymagają żadnego urządzenia

Możesz użyć opcji --host dla Atest, aby uruchomić tylko testy skonfigurowane na hoście, które nie wymagają żadnego urządzenia. Bez tej opcji Atest przeprowadzi oba testy, te wymagające urządzenia i te działające na hoście i nie wymagające żadnego urządzenia. Testy zostaną przeprowadzone w dwóch oddzielnych pakietach.

atest [--test-mapping] --host

Zidentyfikuj grupy testowe

Grupy testowe można określić w poleceniu Test. Poniższe polecenie uruchomi wszystkie testy po przesłaniu związane z plikami w katalogu src/project_1, który zawiera tylko jeden test (C).

Możesz też użyć :all , aby uruchomić wszystkie testy niezależnie od grupy. Poniższe polecenie uruchamia cztery testy (A, B, C, X):

atest --test-mapping src/project_1:all

Uwzględnij podkatalogi

Domyślnie uruchomienie testów w TEST_MAPPING za pomocą Atest spowoduje uruchomienie tylko testów presubmit skonfigurowanych w pliku TEST_MAPPING w CWD (lub podanym katalogu) i jego katalogach nadrzędnych. Jeśli chcesz uruchomić testy we wszystkich plikach TEST_MAPPING w podkatalogach, użyj opcji --include-subdir aby wymusić włączenie przez Atest również tych testów.

atest --include-subdir

Bez opcji --include-subdir narzędzie Atest uruchomi tylko test A. Dzięki opcji --include-subdir narzędzie Atest uruchomi dwa testy (A, B).

Obsługiwany jest komentarz na poziomie linii

Możesz dodać komentarz w formacie // na poziomie wiersza, aby uzupełnić plik TEST_MAPPING opisem ustawień poniżej. ATest i Federacja Handlowa wstępnie przetworzą TEST_MAPPING do prawidłowego formatu JSON bez komentarzy. Aby plik JSON był czysty i łatwy do odczytania, obsługiwane są tylko komentarze w formacie // na poziomie wiersza.

Przykład:

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